Role-Based Entitlements let you define business policies about who should be granted entitlements in your environment. Using an Entitlement Policy (an enhanced eDirectory dynamic group), you define the users who should be granted entitlements based on dynamic search criteria, such as a job title of "Tester." You can manage exceptions using a static inclusion and exclusion list for the policy.
After defining the users for whom the policy should apply, you specify the entitlements you want those users to be granted on connected systems. You can also grant rights in eDirectory, as you can for any dynamic group.
Entitlements on connected systems are granted by DirXML drivers that are configured to support Role-Based Entitlements.
This model of administering business policies is different from the traditional method of provisioning with Identity Manager, because you specify the business policies upstream from the DirXML driver configuration.
Traditionally, entitlements on connected systems are administered on a per-driver basis, solely by creating and editing driver configuration policies such as the ones you create with Policy Builder. In this traditional distributed model, a different administrator often controls each DirXML driver and connected system, and the business policies that determine whether a user gets resources on that system are "hard-coded" in the driver configuration policies for each connected system driver separately.
The Role-Based Entitlement model fits an environment where one or a few administrators have authority to control business policies. This kind of administrator needs to understand Identity Manager in general but does not necessarily need a lot of Identity Manager or XSLT expertise to use the Role-Based Entitlements interface.
Another difference between Role-Based Entitlements and traditional Identity Manager administration is that Entitlement Policies make changes directly in a production environment. Traditionally, changes to driver configurations are tested in a lab first. Entitlement Policies make it easier to make changes to business policies, but you should use caution when making these changes in your production environment. (For suggestions, see Keeping Accounts Safe.)
To help you understand the differences, consider this scenario.
You want to automatically provision new employees with the job title of "Tester" by giving them two accounts:
Using the traditional method, an Identity Manager developer would use Policy Builder or a style sheet to "hard-code" the business policy in the driver configurations for the DirXML Driver for JDBC and the DirXML Driver for GroupWise. However, using Role-Based Entitlements, you create an Entitlement Policy and define dynamic membership for the job title of "Tester."
An Identity Manager developer would also need to have the DirXML Driver for GroupWise and the DirXML Driver for JDBC configured to support Role-Based Entitlements. The drivers would grant accounts to users who met the dynamic membership criteria.
The result is the same up to this point. Using either method, users with the job title of "Tester" are automatically granted an account. However, using Role-Based Entitlements to change this business policy requires less Identity Manager expertise.
After setting up the business policy, you find out that you also need to grant the same kinds of accounts to users with the title of "Testing Manager."
Using the traditional method, an Identity Manager developer would use Policy Builder to "hard-code" the changes to business policy in two places:
However, using Role-Based Entitlements, you apply your knowledge of LDAP filters to easily add the additional user criteria to the dynamic membership in the Entitlement Policy, without editing the DirXML Script. Both the JDBC Driver and the GroupWise driver grant the accounts to the correct users without changes to the driver configurations.