locked
Acropolis, Authorization and AzMan. RRS feed

  • Question

  • Will authorization in Acropolis support the concepts of Operations and Scopes, in addition to Roles ?
    Will Acropolis integrate with Windows Authorization Manager (AzMan) ?


    We need configurable Role-Operation assignments, that can be changed post-deployment with no code changes. Something that .NET out-of-the-box seems to be completely missing. Roles, Tasks, Operations, and vitally important Scopes - i.e. what AzMan provides. Some essential functionality that authorization needs:

    - AccessCheck function that checks whether a user has access to a specific operation, optionally within given scope (or scopes). Not the extremely limited .NET IsInRole method. I don't care what role a user is in. I care what operations they have access to.
    - AccessCheck - check multiple operations in a single call - takes an array of operations.
    - Scopes - essential for allowing a user different roles for different things. For example, in large-scale organizations, a user may have certain roles for one department/division, and different roles for other department/divisions.
    - Application-wide roles, not associated with a scope
    - Ability to assign windows-groups to roles (not just users).
    - Role hierarchies, to allow roles to be created from other roles.
    - Multi-application support – use a single component across all your products.
    - Enterprise roles – to allow a user to be added to a role that spans multiple applications (either via windows groups assigned to roles, or store-level application groups)
    - It would be really cool if this could be done via attributes as well. Some thoughts on that here:
    http://www.leastprivilege.com/CommentView.aspx?guid=3efa5ef5-4aab-4633-bdb2-7ce7d2c5f427

     

    Some things AzMan seems lacking though:
    No pure managed code implementation (currently accessed via COM interop).
    No ability to plug in your own persistance layer, e.g. to save to a specific database such as Oracle, etc.


    If Acropolis is aimed to LOB developers (like me) then the authorization model needs to be a proper Role Based Access Control system (RBAC) , similar to Azman. Not the very limited model that  .NET's IsInRole provides.

     

    Thanks,
    Andy Mackie


     

    Tuesday, July 17, 2007 8:02 AM

Answers

  • Andy, Lee – Thanks for your great questions and comments. Sorry for the delay in replying – your questions have caused quite a few discussions here on the Acropolis team on how best to address your requirements .

     

    It’s difficult to balance providing a simple model that covers most cases, whilst making it extensible and flexible enough to cover the more advanced cases. The Acropolis ‘philosophy’ has been to limit the number of ‘core’ concepts to a minimum and to make them as simple as possible, and then to allow higher level patterns and abstractions to be built on top of them. So the question is, what is the required ‘core’ concept for the Acropolis authorization model which is simple for most cases but can scale to the enterprise scenarios you describe above.

     

    Our current design allows ‘service’ components to be plugged into an application (where a service component is really just a chunk of functionality that doesn’t have an associated UI). Service components very often front real web services and act as a go between (service agent) between the app and the web service, providing client-side caching, offline support, etc. This is how we anticipated authorization working in an Acropolis application – you’d bring in some flavor of an Authentication Service which would represent whatever authorization system you wanted to integrate your application into. We hope to provide a number of pre-defined services out of the box to represent common providers – so one of these could be an AzMan provider for example.

     

    But then the issue becomes how you actually use your chosen authentication service within the application. We wanted to provide integrated support for some core authorization concepts and we’d identified role-based applications as an important scenario. In this case, you’d be able, say, to mark a part, form, or command as requiring a certain role and the system itself would call the authorization service to determine the user’s current role and enable/disable the right parts of the app for you. This has the benefit of being nice and simple but doesn’t cover your scenarios above so we’d need lower level hooks so that you can get the system to take operations and scopes into account instead of just role.

     

    So we don’t yet have a design that would fulfill all your requirements out of the box, but with a bit of tweaking and a few custom components you should be able to achieve most of them. Unfortunately, the current CTP’s do not have any support for authorization yet of course…

     

    Finally, I should say that I am not sure if there are any plans to provide a managed wrapper or managed version of AzMan. I’ll try and find out if there are any plans afoot…

     

    Thanks,

     

    David.

     

    Monday, August 20, 2007 6:11 PM

All replies

  • Thanks Andy for this post. You raise the exact same issues we are looking at currently with our WPF/CAB Smart client. AzMan seems the best option for us at the moment but surely a managed code version should be out by now. Using interop does give AzMan an un-supported microsoft feel about it.

    Each of the functionality points you make here are the ones we are looking for in a Security model.

    Lee Campbell

    Tuesday, July 31, 2007 7:08 AM
  • Andy, Lee – Thanks for your great questions and comments. Sorry for the delay in replying – your questions have caused quite a few discussions here on the Acropolis team on how best to address your requirements .

     

    It’s difficult to balance providing a simple model that covers most cases, whilst making it extensible and flexible enough to cover the more advanced cases. The Acropolis ‘philosophy’ has been to limit the number of ‘core’ concepts to a minimum and to make them as simple as possible, and then to allow higher level patterns and abstractions to be built on top of them. So the question is, what is the required ‘core’ concept for the Acropolis authorization model which is simple for most cases but can scale to the enterprise scenarios you describe above.

     

    Our current design allows ‘service’ components to be plugged into an application (where a service component is really just a chunk of functionality that doesn’t have an associated UI). Service components very often front real web services and act as a go between (service agent) between the app and the web service, providing client-side caching, offline support, etc. This is how we anticipated authorization working in an Acropolis application – you’d bring in some flavor of an Authentication Service which would represent whatever authorization system you wanted to integrate your application into. We hope to provide a number of pre-defined services out of the box to represent common providers – so one of these could be an AzMan provider for example.

     

    But then the issue becomes how you actually use your chosen authentication service within the application. We wanted to provide integrated support for some core authorization concepts and we’d identified role-based applications as an important scenario. In this case, you’d be able, say, to mark a part, form, or command as requiring a certain role and the system itself would call the authorization service to determine the user’s current role and enable/disable the right parts of the app for you. This has the benefit of being nice and simple but doesn’t cover your scenarios above so we’d need lower level hooks so that you can get the system to take operations and scopes into account instead of just role.

     

    So we don’t yet have a design that would fulfill all your requirements out of the box, but with a bit of tweaking and a few custom components you should be able to achieve most of them. Unfortunately, the current CTP’s do not have any support for authorization yet of course…

     

    Finally, I should say that I am not sure if there are any plans to provide a managed wrapper or managed version of AzMan. I’ll try and find out if there are any plans afoot…

     

    Thanks,

     

    David.

     

    Monday, August 20, 2007 6:11 PM