Is it possible to use AzMan for role based authorization on objects which are created at runtime?

Question

Is it possible to use AzMan for role based authorization on objects which are created at runtime? If yes how can this be done?

For Example:

If an object of class "CustomAlert" is created at runtime, I am trying to see if I can have different rules for different objects of the class "CustomAlert". If an object is created by using a specific user's identity, More permissions are available for that user considering him to be CREATOR/OWNER of the object. Only the creator/owner can modify the object.

Answer 1

Azman supports role-based security but it's based on roles only - not on ACLs. If a particular user is logged in, then they have specific permissions based on who they are, but these permissions are just static values - they could be made to apply to all objects of a given type, but not differ according to specific attributes of particular instances of that type.

Answer 2

It is certainly possible to use AzMan for this. I have implemented several applications with this form of resource and role based security. AzMan is actually VERY flexible, and I've also implemented a resource hierarchy (think Windows file system security), with custom users and groups and full inheritance of roles throughout the hierarchy, along with the ability to deny operations at any level. To do this you need to understand AzMan Scopes.

AzMan Scopes allow you to create individual role/operationsets for a particular resource. This resource can be anything you choose, it's just a string identifier to AzMan. These roles/operations are in addition to any application level assigned roles.

The way I've implemented it previously is to use the object's id as the scope name. Ideally for simplicity this should be a GUID (though it does make the MMC application very messy), but equally you could use a "type-id" format i.e. "CustomerAlert-1" (much friendlier in MMC app). When performing an AccessCheck in azman, you pass the scope name to AccessCheck (at the moment it only takes a single scope, even though the AccessCheck definition allows an array).

I'll run through an example of how to do this (for anybody else struggling) ...

1. Create operations such as CustomerAlertView, CustomerAlertEdit, CustomerAlertDelete at the application level.
2. Create a role definition called CustomerAlertOwner at the application level.
3. Add all the operations to the CustomerOwner role.
4. In your app, create a Scope called "CustomerAlert-1".
5. Create a Role Assignment called "Owner" on the scope.
6. Add the CustomerAlertOwner role definition to the "Owner" role assignment.
7. To this Owner role, add the customer/user "Dave".
8. Now when you do an access check in say DeleteCustomerAlert(), you simply pass the id of the CustomerAlertDelete operation and the type/id of the object that you want to delete as the scope i.e. "CustomerAlert-1"

For object property-based access checks (i.e. locking out read/write of certain properties), there are 2 approaches I can think of .. first is to assign operations in the objects scope for each property and access type i.e. PropertyNameGet, PropertyNameSet, PropertyAddressAdd. You can simplify this by creating the operations at the application level and using tasks/role to group commonly used permission sets. The other way is to use the scope for each property (CustomerAlert-1-Name), but this would be messy and is not as efficient, as you'll need to separately load multiple scopes when accessing a given object.

You should bear in mind that you cannot explicitly deny an operation in AzMan, you just don't assign a role for the user in the application/scope. This means certain types of resource hierarchies (groups/users) etc. can be more difficult ot implement.

If you need any further help with AzMan, feel free to ask .. I've covered most scenarios.