Novell IDENTITY MANAGER 3.6.1 - ENTITLEMENTS, Manual

Page: 10 / 44

10 Identity Manager 3.6.1 Entitlements Guide
no
vd
ocx
(e
n)
13
Ma
y 20
09
Accountant role that requires access to the Accounting group in Active Directory. The
Role Service driver grants the Active Directory Group Membership entitlement to the
user.
Š
User Application Workflow-Based Provisioning: A provisioning workflow grants the
entitlement to the user. For example, a new employee is added to the HR system, which
causes a User object to be created in the Identity Vault. Creation of the new User object
initiates a workflow that grants the Active Directory User Account entitlement to the user.
2. When an entitlement is added to or removed from a user’s DirXML-EntitlementRef attribute,
any entitlement-enabled drivers begin to process the event. Only drivers that have the DirXML-
EntitlementRef attribute added to their Subscriber channel filter can monitor users for
entitlement changes.
3. The driver processes the entitlement event against the Subscriber channel policies. If the
entitlement event is for an entitlement that applies to the driver, the policies are processed.
Otherwise, no processing occurs. In the diagram above, the Grant User Account policy is
processed because 1) the Active Directory User Account entitlement was added to the user’s
DirXML-EntitlementRef attribute and 2) the User Account entitlement is defined on the Active
Directory driver. If the Active Directory User Account entitlement is later removed from the
user’s DirXML-EntitlementRef attribute, the Revoke User Account policy is processed.
4. The policies trigger the granting or revoking of access to the entitled resource. In the diagram
above, the Grant User Account policy triggers the creation of a user account in Active
Directory.
1.2 Why Use Entitlements?
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
Section 1.1, “How Entitlements Work,” on page 9 , 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.