Reputation: 781
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.
Upvotes: 0
Views: 1351
Reputation: 404
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) ...
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.
Upvotes: 4
Reputation: 99495
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.
Upvotes: 0