with identity manager 2 we introduced the role-based entitlements (rbe) framework. it allows you to grant or revoke resources through a common architecture based on role membership. with identity manager 3 we expanded the framework to also allow for approval-based resource provisioning. the documentation indicates that role-based and approval-based provisioning are mutually exclusive per resource. true?
roles let you specify static members (and non-members) and dynamic members. the dynamic member feature lets you specify a query that, on evaluation, returns the list of members. this way you can easily set up a policy called “managers” and have it gather its members by querying “class-name equals User AND isManager equals TRUE” instead of manually having to find and add all managers.
approval flows, on the other hand, usually don’t include any dynamics other than finding the next approver. the approver approves or declines a resource request. the reasons an approver bases her/his decision on are beyond the reach of the software controlling the approval flow.
given the fundamental differences between the two, can we assume they are mutually exclusive for a single resource or even the whole provisioning system? e.g. does it make sense to allow access to an application be requested and at the same time grant that same access based on a role? absolutely! eventhough being black and white, role-based and approval-based make up a the perfect marble cake in a good architecture:
- identify resources which can be granted based on roles and which do not need approval in addition to the role membership (which can be seen as a passive approval). once this type of resources has been identified, rbe can be used to create a fully-automated role-based provisioning system.
- define whether exceptions can occur in the above architected system. what if a manager wants to delegate a performance management task to a senior employee with no manager grade but the role-based provisioning system only provisions managers to this application? this is definitely an exception that need to be taken care of. here comes the marble cake: approval-based provisioning can perfectly complement role-based provisioning to handle exceptions in a secure and policy compliant manner.
- identify resources which always need approval for compliance or other reasons. these resources should be excluded from role-based provisioning unless the roles are provisioned approval-based. so there are two approaches: either force approval for each single resource or force approval for role assignments and then have the roles grant access to all the resources necessary to execute that role.
in my next post i will give some technical insights on how to best make role-based and approval-based provisioning work together.