Automated Propagation of Role Changes to Role Members

The role propagation feature in IdentityIQ allows any changes made to a role, including new and removed roles, changes in hierarchy, and changes in entitlements, to be propagated to all identities that are assigned that role. This allows you to use the role model as an authoritative source for requested access.

Note: Entitlements that were detected are not removed from an identity during role propagation, unless they are also part of an assignment.. Only those entitlements that were assigned, individually or as part of a role assignment, are removed during propagation.

Examples of role changes include:

  • Role requirements changes, such as adding or removing an entitlement

  • Role Inheritance changes, such as disabling or enabling role

  • Changes to the list of required roles are needed

Globally Enabling Role Propagation

To use role propagation, the feature must be enabled globally. This is done in the gear menu > Global Settings > Configuration > Roles tab.

To enable role propagation, select the Allow propagation of role changes option on the Roles tab.

How Roles Are Propagated

Once role propagation is enabled, role changes can be automatically provisioned when the role propagation task is run. Changes are provisioned to all identities that are assigned the role that is being propagated.

When a role is changed, the change is saved as a RoleChangeEvent. The Propagate Role Changes task processes these events, provisioning the role changes to the identities that have that role assigned directly or indirectly.

Changes are saved and provisioned in the order they were created; in other words, in a "first in, first out" sequence. Consider this example of role changes, made in this sequence:

  1. Add entitlement A

  2. Remove entitlement A

In this example, the end result is that the identities with this role should not have entitlement A. If the sequence were reversed, the end result would be that the identities would have entitlement A. Understanding the sequential nature of role changes is important for error handling and troubleshooting.

The provisioning plan for all role change events is calculated before the task starts, when the role change occurs, and only role change events created before the Role Propagation task runs are processed by the task during that run. This means that changes to roles that are made after a role propagation task has begun will not be included in that run of the task.

To learn more, see Propagate Role Changes.

Troubleshooting and Managing Errors in Role Propagation

There are several ways you can manage errors and troubleshoot role propagation activity.

A role propagation task can be configured with a "Number of minutes task should run" setting, which is the maximum number of minutes the task should run before terminating. After each event is processed, IdentityIQcompares the actual task duration to the specified maximum; if the task has run out of time, the task is terminated without proceeding to the next event. Note that the duration is not checked in the middle of an event, so an event will not be cut off without having a chance to finish.

When an error occurs that causes an identity to failing on a given role change event, IdentityIQ does not delete the role change event. It keeps track of any identity that failed for the event, and on a second run of the task, can process the role change event only for those identities that failed in an earlier run.

If a failure occurs that can't be resolved with a retry, the role change event can potentially stay "stuck" in the processing queue indefinitely. The Role Change Propagation Task includes a parameter that allow the pruning of stuck events: Maximum failures before event pruning. This parameter sets the number of times a role change event can fail to progress before it is pruned. A failure to progress is defined as zero successes on the event during the task. Events that are blocked by other pending events are not counted as failing to progress. If this value is left blank, the event will never be pruned until it has been fully processed.

The task also includes a Maximum failure threshold parameter that limits how many identities can fail to be provisioned by a single role change event, expressed as a percentage of the total number of identities affected by the event. All partitions for a role change event are allowed to run to completion, and once finished, the transition request computes the actual failure percentage and compares it to the maximum failure threshold. If the percentage is exceeded, the propagation terminates. Note that this does not mean that a single role change event will stop as soon as it hits the maximum; it means that if an event exceeds the maximum, no more subsequent events will be processed.

Once the task has run, the Task Result UI shows various statistics, including errors. For role propagation, the Number of identities failed/pending and Number of stale events pruned statistics can be useful in troubleshooting errors. In the Debug pages, the TaskResult and RoleChangeEvent objects can also be reviewed for troubleshooting purposes.