14.11 Automated Access Provisioning and Deprovisioning

You can set up business roles to automatically request provisioning and deprovisioning of authorized resources for users in the business role by selecting the auto-grant or the auto-revoke setting for each resource. Identity Governance performs business role detections and evaluates business role membership changes to determine whether to issue the auto requests. During business role detection, Identity Governance only evaluates whether auto requests should be issued. After all business role detections including checking for pending requests, it determines if the auto requests including compensating requests should be issued. Requests are then sent to the fulfillment system where the fulfillment system handles them according to the rules specified in your system fulfillment configuration.

NOTE:During detection, Identity Governance monitors when a user gains or loses an authorization, or when an authorization changes its auto-grant or auto-revoke policy. When Identity Governance observes these kinds of changes, it triggers an evaluation of whether it needs to issue the auto requests. However, detection does not monitor changes in user resource assignments. Authorization for a resource is not the same thing as being assigned a resource. Since the detection process does not monitor the assignment changes, assignment changes do not trigger an evaluation of whether to issue the auto requests.

The events that trigger Identity Governance to perform business role detections do not necessarily result in Identity Governance issuing auto-grant or auto-revoke requests. The rules that trigger a detection are different from the rules that govern whether Identity Governance will issue the auto requests. For example, deactivating a technical role that is an authorized resource of a business role triggers a business role detection, but does not result in an auto-revoke request or changes to any current auto-grant or auto-revoke request. Publication of application sources trigger detection but do not necessarily result in Identity Governance issuing the auto requests.

14.11.1 Understanding Business Role Detections

Business role detection is a process where Identity Governance updates business role memberships and business role authorizations. After business role memberships and authorizations are updated, Identity Governance might also issue the auto-grant and the auto-revoke requests.

There are currently three types of business role detection:

All business roles

Identity Governance processes all published business roles in this type of detection. The following events trigger this type of detection:

  • Publication of identities and applications

  • Creation, deletion, or modification of technical roles

Business roles with expiring memberships or authorizations

Identity Governance processes business roles that have memberships or authorizations with an expiration date. Identity Governance automatically runs this type of detection every 24 hours.

Single business role

Identity Governance processes exactly one business role in this type of detection. The following events trigger this type of detection:

  • Publication of a business role

  • Deactivation or deletion of a published business role

  • Curation (manual or bulk update) of users

A business role detection, regardless of its type, has two phases. In phase one, it calculates business role memberships and authorizations. It also keeps track of all of the following types of authorization changes and uses this information in phase two:

  • User gains a new authorization for a resource that is auto-granted.

    This might occur because a user became a member of a new business role, or a new authorization was added to a business role the user is already a member of.

    NOTE:If a business role authorizes a technical role and a new permission is added to the technical role, it ultimately results in a new authorization for that permission for all of the business role members.

  • An authorization that is auto-granted and was not previously in its validity period enters its validity period

  • An authorization that is in its validity period changes from not auto-granted to auto-granted

  • User loses an authorization for a resource that is auto-revoked

    This might occur because a user lost membership in a business role, an authorization was removed from a business role the user is a member of, the business role is deleted, or the business role is deactivated.

    NOTE:When evaluating whether an auto-revoke request should be issued, Identity Governance ignores the loss of authorizations that occurs because an administrator deactivated the business role.

    If a business role authorizes a technical role and a permission is deleted from the technical role, it ultimately results in the members of the business role losing their authorization for that permission. If the technical role itself is deleted, it ultimately results in the members of the business role losing authorization for all of the permissions that were contained in that technical role. However, if a technical role is simply deactivated as opposed to being deleted, business role authorizations stemming from that technical role are not lost.

  • An authorization that is auto-revoked and was not previously in its validity period exits its validity period

  • An authorization that is not in its validity period changes from not auto-revoked to auto-revoked

During phase one, after Identity Governance calculates a business role's membership and authorizations, it determines what other business roles include the members of the business role and schedules single-role detections for each of those business roles. This occurs whether Identity Governance detects BR1 during an all business role detection or during a single-role detection for just BR1 because changes to the membership of a business role affect the membership of any business roles that include it. For example, if BR1 is included by BR2 and BR3, after calculating membership and authorizations for BR1, Identity Governance schedules single-role detections for BR2 and BR3.

In phase two of detection, using the information collected in phase one, Identity Governance determines what, if any, auto requests it should issue. For specific conditions that could result in auto-grant requests being issued, see Section 14.11.2, Automatic Provisioning Requests. For specific conditions that could result in Identity Governance issuing auto-revoke requests, see Section 14.11.3, Automatic Deprovisioning Requests.

Some of the conditions that could result in Identity Governance issuing an auto-grant or an auto-revoke request involve compensating for in-progress requests that would change whether a user has a particular resource. An administrator can configure Identity Governance to compensate for in-progress requests. For more information about compensating requests, see Section 14.11.4, Managing Compensating Requests.

Although Identity Governance might issue auto-grant requests and auto-revoke requests in phase two of a business role detection, the requests might not ever be fulfilled for a variety of reasons. This results in situations where there might be users whose assigned resources are inconsistent with the auto-grant or the auto-revoke policies, or users that have pending grant or revocation requests for resources that, if fulfilled, would cause them to be inconsistent with the auto-grant or the auto-revoke policies. Identity Governance does not automatically check for such assignment inconsistencies during normal business role detection as there would be additional overhead to do so, thus slowing down the business role detection process. Instead, Identity Governance enables administrators to manually check for such inconsistencies and fix them. For more information, see Section 14.11.5, Managing Auto Request Inconsistencies.

Depending on a variety of factors, business role detections can potentially take some time to complete. Identity Governance allows administrators to monitor the progress of business role detections and to see detailed information about in-progress and completed business role detections. For more information, see Section 14.11.6, Monitoring Business Role Detections.

14.11.2 Automatic Provisioning Requests

During phase one of business role detection, Identity Governance gathers various types of authorization change events which trigger an evaluation of whether to issue an auto-grant request. The change events include user gaining a new authorization for a resource that specifies auto-grant, an auto-granted authorization entering its validity period, or an authorization in its validity period changing from not auto-granted to auto-granted. In phase two of business role detection, Identity Governance evaluates what, if any, auto-grant requests to issue.

Identity Governance issues an auto-grant request only if all of the following conditions are satisfied:

  • The user + resource ends up being authorized after phase one business role detection.

  • The user either is currently not assigned the resource (for applications assigned means the user has an account in the application) or there is a pending request to revoke the resource from the user and the request is one of the types that an administrator has specified as being compensatable.

    NOTE:Identity Governance considers a request as pending until it is in a final state. Final states include the following states: rejected by fulfiller, fulfillment error, fulfillment timed out, completed and verified, completed and not verified and verification ignored, or completed and verification timed out.

  • There is no previously issued auto-grant request from a business role detection for the user + resource that is still in-progress. Auto-grant requests in a final state (see above) are obviously no longer in progress. In addition, a request that has completed (marked as fulfilled) is not considered to be in-progress, even though it might not yet be in verified, not verified and verification ignored, or verification timed out state.

14.11.3 Automatic Deprovisioning Requests

During phase one of business role detection, Identity Governance gathers various types of authorization change events which trigger an evaluation of whether to issue an auto-revoke request. The change events include user losing an authorization for a resource that specifies auto-revoke, an auto-revoked authorization exiting its validity period, or an authorization in its validity period changing from not auto-revoked to auto-revoked. In phase two of business role detection, Identity Governance evaluates what, if any, auto-revoke requests to issue.

Identity Governance issues an auto-revoke request only if all of the following conditions are satisfied:

  • The resource is not authorized for the user by any business role.

  • The user either is currently assigned the resource (for applications assigned means the user has an account in the application), or there is a pending request to grant the resource to the user and the request is one of the types that an administrator has specified as being compensatable.

    NOTE: Identity Governance considers a request to be pending until it is in a final state, which include the following states: rejected by fulfiller, fulfillment error, fulfillment timed out, completed and verified, completed and not verified and verification ignored, or completed and verification timed out.

  • There is no previously issued auto-revoke request from a business role detection for the user + resource that is still in progress. Auto-revoke requests in a final state (see above) are obviously no longer in progress. In addition, Identity Governance does not consider a request that has been completed (marked as fulfilled) to be in-progress, even though it might not yet be in verified, not verified and verification ignored, or verification timed out state.

The above conditions apply only to published business roles. Identity Governance ignores deactivated business roles when determining if all conditions are met. The following scenario provides an example of automatic deprovisioning.

Scenario 1, An authorized permission is removed from a business role:

  1. BR1 authorizes permission X and specifies auto-grant and auto-revoke on it.

  2. User A is a member of BR1 and currently has permission X.

  3. A business role administrator removes the permission X authorization from BR1 and re-publishes BR1. This triggers business role detection on BR1.

  4. Identity Governance detects that Permission X is no longer authorized for BR1, which means that all members which had authorizations for permission X from BR1 lose that authorization. User A is one of those members that loses the authorization.

  5. The loss of the user A's authorization for permission X causes Identity Governance to evaluate whether it should issue an auto-revoke request to remove permission X from user A.

  6. Identity Governance issues an auto-revoke request to remove permission X from user A because all conditions for automatic deprovisioning are met:

    1. User A no longer has any authorization for permission X from any other business role,

    2. User A currently has permission X, and

    3. There is no in-progress auto-revoke request to remove permission X from user A.

14.11.4 Managing Compensating Requests

Identity Governance examines both the current state of Identity Governance catalog and pending requests that might alter that state to determine if a user has a resource when it evaluates whether to issue an auto-grant or an auto-revoke request. Identity Governance compensates for pending fulfillment requests that would change whether the user has a resource. Identity Governance could grant a request to compensate for a pending revoke request, and it could issue a revoke request to compensate for a pending grant request.

Administrators can configure the types of requests for which Identity Governance might issue a compensating request. The type of request indicates the Identity Governance process from which the request originated. It might be an access request, a review, or a resolution of separation of duties violations.

NOTE:Identity Governance always compensates for pending requests that originated from the business role detection process.

To specify types of request that should generate compensating requests:

  1. Log in to Identity Governance as a Business Role or Global Administrator.

  2. Select Policy > Business Roles > Manage Auto Requests.

  3. Select the additional type of requests for which the system should automatically compensate.

The following scenarios provide a few examples of when Identity Governance would issue compensating requests.

Scenario 1, User gains an auto request enabled permission that was lost but which Identity Governance considers as still authorized:

  1. Business role BR1 and business role BR2 both authorize permission X and both specify auto-grant and auto-revoke.

  2. User A is a member of BR1 and currently has permission X.

  3. An administrator or the system modifies user A's attributes so that they are no longer a member of BR1. Identity Governance’s real time identity collection detects this change and user A loses its authorization for permission X.

  4. Identity Governance issues a revoke request to remove permission X from user A.

  5. The application containing permission X removes permission X from user A.

  6. An administrator or the system modifies user A's attributes again so that it becomes a member of BR2 and as such is authorized for permission X. The application containing permission X has removed permission X from user A, but Identity Governance catalog still shows that user A has permission X because no one executed collection and publication of that application since Identity Governance issued the revoke request. Therefore, Identity Governance would not normally issue an auto-grant request for permission X.

    However, because the revoke request for permission X still shows that it is pending verification, and you configured Identity Governance to issue compensating grant requests for this type of revoke request, Identity Governance issues a compensating grant request for user A to be given permission X.

Scenario 2, User loses an auto request enabled permission that was granted but which Identity Governance considers as not authorized:

  1. Business role BR1 authorizes permission X and specifies auto-grant and auto-revoke.

  2. User A has no permissions but an administrator or the system changes the user’s attributes making it a member of BR1. Identity Governance's real time identity collection detects this change and user A becomes a member of BR1 and gains an authorization for permission X.

  3. Identity Governance issues a grant request for user A to have permission X.

  4. The application that contains permission X assigns permission X to user A.

  5. User A's attributes are changed again so that they are no longer a member of BR1. User A's authorization for permission X is lost. The application containing permission X has assigned permission X to user A, but Identity Governance catalog still shows that user A does not have permission X because no one executed collection and publication of that application since Identity Governance issued the grant request. Therefore, Identity Governance would not normally issue an auto-revoke request for permission X.

    However, because the grant request for permission X still shows that it is pending verification and you configured Identity Governance to issue compensating revoke requests for this type of grant request, Identity Governance issues a compensating revoke request to remove permission X from User A.

14.11.5 Managing Auto Request Inconsistencies

Although Identity Governance might issue auto-grant requests and auto-revoke requests in phase two of a business role detection, the requests might not ever be fulfilled for a variety of reasons. The fulfillment system might handle the requests in a different order than they were issued, the fulfillment system could reject the request, or there could be an error fulfilling the request. In addition, external systems might change resource assignments without Identity Governance issuing a request to do so. Resource assignment changes are not examined by Identity Governance when determining if it should issue an auto-grant or an auto-revoke requests as there would be additional overhead to do so, thus slowing down the business role detection process.

These kinds of scenarios can result in situations where there might be users whose assigned resources are inconsistent with the auto-grant or the auto-revoke policies, or users that have pending grant or revocation requests for resources that, if fulfilled, would cause them to be inconsistent with the auto-grant or the auto-revoke policies.

Auto-grant request inconsistencies occur when there are permissions or applications which business roles authorize and normally would auto-grant to users, but which the users either do not currently hold or would not hold in the future (due to a pending revoke request for the same resource). Here is one scenario where such an inconsistency could occur:

  1. User A becomes a member of BR1 that authorizes permission X and specifies that X should be auto-granted. Identity Governance does not issue an auto-grant request because user A already has permission X.

  2. The application which contains permission X removes permission X from user A without Identity Governance issuing any request to do so because external applications might assign or unassign resources to or from users without receiving any request from Identity Governance to do so.

  3. Identity Governance collects and publishes the application which contains permission X and updates its catalog to reflect that User A no longer has permission X. After the publication, Identity Governance triggers the business role detection. But, Identity Governance does not issue an auto-grant for user A to have permission X, because detection did not see any authorization changes (the fact that the business role authorizes user to have permission X did not change), and detection does not check to see if there were assignment changes.

    This results in an inconsistency between the auto-grant policy and the assignment state with respect to user A and permission X.

Auto-revoke request inconsistencies occur when Identity Governance finds a permission or an application which are currently held or will be held in the future (due to a pending grant request for the same resource) but the resource is not authorized by any business role the user is currently a member of and the resource was auto-revoked by a business role the user was previously a member of. Here is one scenario where such an inconsistency could occur:

  1. User A is a member of BR1 that authorizes permission X and specifies that X should be auto-revoked.

  2. User A's attributes change in a way that causes it to lose its membership in BR1. Identity Governance's real time collection process detects the change. After it processes the change, Identity Governance triggers a business role detection. The detection causes Identity Governance to issue an auto-revoke request to remove permission X from user A.

  3. The application that contains permission X removes permission X from user A. Later, however, the application restores permission X to user A. Again, remember that external applications might assign or unassign resources to or from users without receiving any request from Identity Governance to do so.

  4. Identity Governance collects and publishes the application which contains permission X. After publication, business role detection is triggered. However, Identity Governance does not issue an auto-revoke request to remove permission X from user A, because detection did not see any authorizations that were lost (user A is still not authorized by any role to have permission X) and detection does not check to see if there were permission assignment changes.

    This results in an inconsistency in the auto-revoke policy for permission X because user A at one time was a member of BR1, and it specified that permission X should be auto-revoked.

Identity Governance does not automatically check for such assignment inconsistencies during normal business role detection as there would be additional overhead to do so, thus slowing down the business role detection process. Instead, Identity Governance allows an administrator to find these inconsistencies and issue new requests to resolve them if needed. It is not a given that you should resolve all such inconsistencies, so Identity Governance does not do it automatically. This is especially true of the auto-revoke inconsistencies - the fact that a user was at one time a member of a business role that specifies that a permission the user holds should be auto-revoked might or might not be sufficient reason to revoke the permission from the user.

To find and optionally resolve inconsistencies:

  1. Log in to Identity Governance as a Business Role or Global Administrator.

  2. Select Policy > Business Roles > Manage Auto Requests.

  3. Select the policy type and click Detect Inconsistencies.

  4. (Conditional) For auto-revoke types, specify the number of days to search for lost business role memberships.

    When searching for auto-revoke inconsistencies, Identity Governance searches for authorizations that specify auto-revoke in business roles that users were previously a member of. It only looks for business role memberships the user lost within the last N days. Identity Governance ignores business role memberships that were lost before N days.

  5. (Optional) In the pop-up window search bar, specify a user name, a permission, or a business role name to search for related inconsistencies.

  6. (Optional) Submit grant or revoke requests for some or all inconsistencies to resolve them.

14.11.6 Monitoring Business Role Detections

Identity Governance enables administrators and support personnel to troubleshoot issues by looking at the progress and results of business role detections.

During business role detection, in addition to various instance times, Identity Governance stores counts of memberships, authorizations, and auto-requests. You might enable collection of more detailed information on the exact memberships, authorizations, and auto-requests that were generated during a detection by setting the following configuration properties in the Identity Governance configuration utility.

IMPORTANT:If you enable collection of detailed information, business role detections slow down and consume more space in the database in order to store the detailed information. Generally, you should enable collection of detailed information only if you are troubleshooting some problem and need more information to determine what is happening.

  • com.netiq.iac.brd.log.detected.members

    When set to true this configuration property causes business role detection to store the list of users who were added to and removed from a business role during the detection.

  • com.netiq.iac.brd.log.detected.auths

    When set to true this configuration property causes business role detection to store the list of authorizations that were added and deleted during the detection.

  • com.netiq.iac.brd.log.detected.autorequests

    When set to true this configuration property causes business role detection to store the list of auto-grant and auto-revoke requests that Identity Governance issued during the detection.

To monitor business role detections:

  1. Log in to Identity Governance as a Business Role or Global Administrator.

  2. Select Policy > Business Roles > Business Role Detections.

  3. (Optional) Specify business role name in the search bar to search for the detection status and details such as detection end time, number of auto-revokes generated for a business role, and so forth.

  4. (Optional) Select the number of business role completed to view additional details such as the number of members that the system added or removed, the number of authorizations that the system granted or revoked, and so forth.

  5. (Optional) Select detections to delete. You should not delete a detection that is currently running.