Both roles-based provisioning and workflow-based provisioning require the use of entitlements. If you use either of these User Application provisioning methods, you must use entitlements.
If you are not using the User Application for roles-based or workflow-based provisioning, you might still want to use Role-Based Entitlements (RBEs) through the Entitlements Service driver. Using Role-Based Entitlements enables you to remove the business logic, or decision-making, from your driver policies. In the example used in How Entitlements Work, the Active Directory driver policies include only the information required to grant or revoke an Active Directory user account. The decision about whether or not a user receives an Active Directory user account is handled through the entitlement agent, not the driver policies. In this case, the entitlement agent is the Entitlements Service driver.
Removing the business logic from drivers provides several benefits:
If you have multiple drivers that are the same (for example, multiple Active Directory drivers) and your business logic changes, you don’t have to change the logic in each driver. The logic only needs to change in the entitlement agent.
You can use any of the three entitlement agents to grant an entitlement to a user. You can even use all three entitlement agents together. However, you should have only one entitlement agent handle an entitlement for a given user. For example, you could have an Active Directory User Account entitlement granted to a user by the Entitlement driver and a Linux User Account entitlement granted to the same user through the User Application’s Role Service driver. However, you should not have the same entitlement (for example, the Active Directory User Account) managed by both the Entitlement driver and the User Application’s Role Service driver. Doing so can cause unintended granting and revoking of the entitlement.