Multiple Role and Account Assignment

IdentityIQ allows roles to be assigned to an identity more than once and applied to different sets of accounts associated with the identity. A second feature allows a role assignment to apply to multiple accounts on the same application.

Multiple Role Assignment

A system and a role-specific option allows a role to be assigned to an identity more than once and have the associated entitlements apply to different accounts.

The model that is used to persist role assignment on an identity includes the accounts to which the role assignment is provisioned. This model is referred to as target account memory. The role assignment can also contain an assignment note that describes why the assignment exists. The assignment note is useful for differentiating multiple assignments. For example, you can have one assignment with a note of Standard Account and a second assignment with a note of Privileged Account.

When a role is assigned, the applicable accounts are selected automatically using rules or through an interactive user interface. The selection of accounts can optionally be a directive to create a new account. Account selection rules can be defined on a role that can contain entitlements that can be provisioned from profiles to automate the selection of applicable accounts. There can be a general rule for the role as well as a rule for every application included in the role profiles.

For Lifecycle Manager access requests, the requestor is prompted, if they are required by the configuration settings, to select the accounts to use for the request. This occurs if multiple accounts already exist on the relevant applications or IdentityIQ is configured to allow a new account to be created and account selection rules did not automatically select the appropriate accounts. The requestor can enter an assignment note during account selection.

When role assignment rules are processed during the Identity Refresh task, the default behavior is to skip any role provisioning that does not explicitly define the target account and to report the number of times provisioning was skipped. The Identity Refresh task can be configured to create required account selection work items if appropriate account selection rules are not defined, but care should be to be taken to ensure that this does not create an inordinate number of work items. To prevent the need for manual interaction, the best practice is to have completely defined account selection rules for all profiles associated with rule-based role assignments where multiple role assignment is allowed.

Details about the accounts that an assigned role applies to and the optional assignment note are displayed in the appropriate user interfaces including: Entitlements tab of the View Identity page, Certifications pages, Lifecycle Manager Current Access, Lifecycle Manager approval work items, and Manage Access Request details. Additionally, these user interfaces have a role listed multiple times if the role is assigned more than once.

Multiple Application Accounts in an Assignment

In a standard role assignment, a role can provision to no more than one account on a specific application. If the role hierarchy contains more than one role that targets the same application, the entitlements for the assigned role are all provisioned on the same account.

An option can be specified on any role that can be contained on a permitted or required list of another role, or any role that contains entitlements that can be provisioned from profiles or any role that contains a provisioning policy, that allows the entitlements in that role to be provisioned to a selected account or to a newly created account. If there is more than one role that can be provisioned that uses this option in the assigned role hierarchy, a different target account (including creating a new account) can be selected for each role.

Role Detection

Roles are detected when an Identity Refresh task runs with the Refresh assigned, detected roles and promote additional entitlements option is selected.

In role detection, IdentityIQ compares the entitlement profiles of each role to the entitlements held by each Identity. Profiles may specify a single entitlement or may specify multiple entitlements, either in "and" relationships, requiring the identity to have all listed entitlements to have the role, or "or" relationships, meaning the identity has the role if they have any of the entitlements. When an Identity’s collection of entitlements meets an IT role profile’s requirements, the role is marked as "detected" for that Identity.

All detected roles store information about the accounts and entitlements that fulfilled the detection. Detection recognizes and persists if a detected role was part of an assignment – for example, if it was explicitly requested in a Lifecycle Manager access request.

A role can be detected more than once if there are role assignments targeting different accounts on the same application. For example, if assigned role A and assigned role B both have required role R, but different target accounts were selected for A and B, there are two detections of R. One for the accounts selected for A and one for the accounts selected for B. This model is necessary to accurately show which accounts and entitlements are included in each role assignment.

Defined IT roles can be detected for Identities based on the entitlements recorded for the Identity in IdentityIQ. Once entitlements are associated as a role for an Identity, the individual entitlements are no longer displayed on the Identity Cube's entitlements page, as they are replaced by the more concise role name. For example, if an Identity already has the time-tracking system's required entitlements for the Timesheet Approval role, this role will be detected for the Identity and will be marked on the Identity Cube in place of the entitlements encapsulated within it. The role-encapsulated entitlements can be shown or hidden in the UI based on a checkbox selection, and any role can be clicked to view the details within it.

Hard and Soft Permitted Roles

A hard permitted role is a role that is requested through IdentityIQ. A soft permitted role is a role that is discovered through aggregation and entitlement correlation, but was not explicitly requested or provisioned using IdentityIQ.

When a role that contains hard permitted roles is unassigned and deprovisioned, the hard permitted roles is also deprovisioned if there are no other dependencies on those roles. If a role containing soft permitted roles is unassigned and deprovisioned, the soft permitted roles are not deprovisioned.

Identity Role Assignments

Role assignments have an assignment id that is used to uniquely refer to the assignment. The user interface does not display this assignment id, but any code that references an assignment needs to use the id to keep a reference from being ambiguous.

When a permitted role is requested through Lifecycle Manager, IdentityIQ records the request in the RoleAssignment model by placing a nested RoleAssignment for the permitted role inside the RoleAssignment for the assigned role. This process defines a hard permitted role.

The identity assignedRoles and assignedBundleSummary attributes are a unique list of roles, and if a role is assigned multiple times, the role is in this list only one time. The identity roleAssignments attribute can contain multiple items for the same role if the role is assigned multiple times.

Existing methods on the identity object related to role assignments remain for backward compatibility, but are marked deprecated and can return incomplete results if multiple assignments are enabled.

Provisioning Plans

If multiple assignments are enabled and exist, a provisioning plan to modify assignments must specify an assignment id to prevent ambiguity. When an assignment is being added and the intention is to create a second assignment, a special assignment id token of new is used.

A single attribute request can contain a list of roles that are to have their assignments changed. When multiple assignments are enabled and exist, each role must be contained in a separate attribute request so that an assignment id can be specified.

The provisioner remains backward compatible and continues to process provisioning plans without assignment ids or role lists.

If multiple assignments are enabled, it is imperative that provisioning plans are well formed and include the correct data to impact the desired change.

When multiple assignments for the role exist, a provisioning plan that includes a request to remove a role assignment by name without an assignment id removes one indeterminate role assignment. When an assignment for a role already exists, a provisioning plan that includes a request to add a role assignment without an assignment id or a new token selects one indeterminate role assignment and provision any missing entitlements.