• Subject may have one entitlement
• Subject must have one entitlement

Examples of indirect entitlements are entitlements/groups granted through Roles and Groups.


EXAMPLE

In the following example, a form is defined to add Technical Role entitlements to users. The expectation is that when the form runs, Technical Roles belonging to users indirectly cannot be added or removed via the form. 

1. There are two Technical Roles in RSA Identity Governance & Lifecycle (TRole1 and TRole2). TRole1 is an indirect entitlement of Business Role BRole1. In the user interface (UI) go to Roles > Roles.

2. User Rita Book has BRole1 which grants her TRole1 as an indirect entitlement. In the UI go to Users > Users > {User Name} > Access tab > Show All.

3. The entitlement form is defined as follows. In the UI go to Requests > Configuration > Request Forms tab > {Form Name} > Fields tab > Edit button.

4. When the form is run and access is requested for user Rita Book, the expected behavior is that TRole2 will be the only Technical Role available to choose from since the user already has TRole1. However, when the Change Item Handling field is defined as one of the following options, 

• Subject may have one entitlement
• Subject must have one entitlement

5. If Change Item Handling is set to Add selected items, the correct behavior occurs, which is, only entitlements not granted to the user whether directly or indirectly are available for selection. Note: Indirect entitlements/groups granted through Roles/Groups, should only be added/removed via Roles and Groups