19.8 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, Identity Governance determines if the auto requests including compensating requests should be issued. If potential SoD violation checking is enabled for detection, before sending the auto request for fulfillment, Identity Governance checks for potential SoD violations and if granting the request results in one or more SoD violations, as defined in the SoD approval policy, the request is sent to an SoD administrator or SoD owner for approval. If the potential SoD violation is approved, the permission or application resource request is then sent to the fulfillment system where the fulfillment system handles them according to the rules specified in your system fulfillment configuration. Note that a request with several potential SoD violations is not sent for fulfillment until all the violations are approved.

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.

Figure 19-4 Business Role (Permissions and Applications) Automated Access Provisioning and Deprovisioning Process

When you specify auto-grant and/or auto-revoke for technical roles, Identity Governance performs two different actions.

  • Identity Governance auto-grants and/or auto-revokes the permissions that make up the technical role, and follows the usual process for granting and revoking permissions

    By default, when technical roles are revoked, fulfillment requests are generated to remove permissions regardless of the business role authorization settings. Administrators can configure Identity Governance to honor business role authorizations so that fulfillment requests are not generated if the permission is authorized by business role membership by setting the com.netiq.iac.request.honorBRoleAuthorizations property to true using the Configuration Utilityconsole mode procedures. Administrators can also control whether fulfillment requests are generated for both auto grant and non-auto grant authorizations only using the com.netiq.iac.request.honorBRoleAutoGrantOnly property.

  • Identity Governance auto-grants (makes) and/or auto-revokes (removes) a technical role assignment as needed. If Identity Governance determines that a technical role assignment should be made or removed, it makes or removes the assignment during business role detection itself and does not generate a fulfillment request. This is because technical role assignments are not provisioned from external data sources, but are provisioned and maintained by Identity Governance. However, if granting a technical role results in one or more potential SoD violations, Identity Governance sends the request through potential SoD violation approval first, as specified in the SoD approval policy.

Figure 19-5 Business Role (Technical Roles) Automated Access Provisioning and Deprovisioning Process when Business

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.

19.8.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 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

  • Collection of identities after change events (also referred to as real time collection)

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

    During this type of event, Identity Governance determines which business roles have membership expressions involving the attributes that were curated and schedules a business role detection for each of those business roles so that their membership is recalculated.

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:

  • A 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 that 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.

  • A 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 that the user is a member of, the business role is deleted, or the business role is deactivated.

    NOTE:When evaluating whether to issue an auto-revoke request, 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 rather than 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 19.8.2, Automatic Provisioning Requests. For specific conditions that could result in Identity Governance issuing auto-revoke requests, see Section 19.8.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 19.8.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 because 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 19.8.5, Understanding 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 19.8.7, Monitoring Business Role Detections.

After business roles are detected, Identity Governance identifies auto-grants that require approval for potential SoD violations resulting from business roles. An administrator can view the status and timeline of those auto-grants if they navigate to Business Roles > Auto Requests > Auto Requests. They can check each request to know the list of business roles that made that request or select a request item status to view the timeline of underlying events associated with that request, including request details and the number of SoD violations the request is contributing to.

19.8.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.

    NOTE:When auto-grant option is enabled for a technical role resource, Identity Governance generates fulfillment requests for the permissions that make up the technical role, but does not generate fulfillment requests for the technical role assignment itself. Instead, Identity Governance makes a technical role assignment immediately if it determines that the user does not currently have the technical role assignment. Because there is no fulfillment request for making technical role assignments, the previous comments about Identity Governance checking for completed and in-progress pending fulfillment requests do not apply in the case of making technical role assignments.

19.8.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 a 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 includes 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 and 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.

    NOTE:When the auto-revoke option is enabled for a technical role resource, Identity Governance generates fulfillment requests for the permissions that make up the technical role, but does not generate fulfillment requests for the technical role assignment itself. Instead, Identity Governance removes a technical role assignment immediately if it determines that the user currently has the technical role assignment. Because there is no fulfillment request for removing technical role assignments, the previous comments about Identity Governance checking for completed and in-progress pending fulfillment requests do not apply in the case of removing technical role assignments.

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 action triggers business role detection on BR1.

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

  5. The loss of 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.

19.8.4 Managing Compensating Requests

Identity Governance examines both the current state of the 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.

NOTE:Identity Governance rules for generating compensating requests are applicable to the permissions that make up the technical role but are not applicable to technical role assignments.

The technical roles are managed and provisioned by Identity Governance itself. Auto-grant and auto-revoke of technical role assignments do not involve generation of fulfillment requests because there is no external data source for technical role assignments. Identity Governance makes or removes a technical role assignment immediately and does not trigger fulfillment requests or compensating requests.

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 Customer, Global, or Business Roles Administrator.

  2. Select Policy > Business Roles > Auto Requests > Configure Compensating 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 the user is no longer a member of BR1. Identity Governance’s real-time identity collection detects this change and user A loses 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 the user 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 the 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 the user a member of BR1. Real-time identity collection in Identity Governance 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 the user is 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 the 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.

19.8.5 Understanding 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. Identity Governance does not examine resource assignment changes when determining whether to issue an auto-grant or auto-revoke request because 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 who 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.

Inconsistency checking for permissions and applications includes checking for pending requests that might cause the permission or application to be held or not held in the future. A request is considered to still be pending even if its status has been changed to completed by a fulfiller (manual or automated provisioning process) and it is waiting for verification because the request might or might not result in the permission or application being held or not held in the future. Verification happens after a publication occurs. Once verification happens, the request will no longer be considered to be pending. Its status will change to either not verified or verified. Although not a final state, not verified is considered by inconsistency checking to no longer be a pending request and such a request is not considered when determining whether the permission or application might be held or not held in the future.

Administrators can manually initiate inconsistency detection for auto-grant and auto-revoke inconsistencies. Identity Governance displays information about the most recent inconsistency detection for six types of inconsistencies: Auto-grant Permissions, Auto-grant Technical Roles, Auto-grant Applications, Auto-revoke Permissions, Auto-revoke Technical Roles, and Auto-revoke Applications. Information includes status, start time, end time, count of inconsistencies detected, who started the detection, who canceled the detection (if canceled), and so forth. If detection is currently running, a spinner icon will be displayed next to a status of Running. The administrator can click a refresh icon in the Action column to start detection if one is not currently running. Once detection has completed, the status will be changed to Completed and authorized users will be able to click the value in the inconsistency count column to see and optionally resolve the inconsistencies that were detected. The user can also download the inconsistency detection results to a CSV file. If no inconsistencies were detected, the count column will have a value of zero.

Auto-grant request inconsistencies occur under the following conditions:

  • One or more business roles authorize a resource (permission, technical role, or application) and specify that the resource is to be auto-granted to users.

  • A user who is a member of one or more business roles either does not currently hold the authorized resource or may not hold the resource in the future due to a pending revoke request. In this context, Identity Governance considers only pending revoke requests that have been configured as compensatable requests.

  • There is no in progress auto-grant request that would grant the resource to the user.

NOTE:There will never be pending revoke requests or in-progress auto-grant requests for technical role assignments because Identity Governance always removes and fulfills technical role assignments immediately.

Here is one scenario where an auto-grant request 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 that contains permission X removes permission X from user A without Identity Governance issuing any request to do so. This can happen 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 that contains permission X and updates its catalog to reflect that User A no longer has permission X. After the publication, Identity Governance triggers business role detection. However, 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 the 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 under the following conditions:

  • A user either has a resource (permission, technical role, or application) or will have the resource in the future due to a pending grant request that is not currently authorized by any business role the user is a member of. In this context, Identity Governance considers only pending grant requests that have been configured as compensatable.

  • The user was at one time a member of a business role that auto-revokes the resource. When checking for revoke inconsistencies, Identity Governance only considers the business roles the user was a member of within the last N days. Memberships held earlier than the last N days are not considered.

  • There is no in progress auto-revoke request that would revoke the resource from the user.

NOTE:There will never be pending grant requests or in progress auto-revoke request for technical role assignments because Identity Governance always removes and fulfills technical role assignments immediately.

Here is one scenario where an auto-revoke request 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 the user to lose membership in BR1. The real-time collection process in Identity Governance 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 that 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.

19.8.6 Detecting and Resolving Inconsistencies

Identity Governance does not automatically check for inconsistencies during normal business role detection because 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.

Submitting new requests to resolve inconsistencies arising from auto-grants can lead to potential SoD violations. So, Identity Governance allows administrators to analyze the requests for possible violations before sending them for fulfillment. They can download the details in a CSV file and analyze all grant requests or selected grant requests for SoD violations.

To find and resolve inconsistencies:

  1. Log in to Identity Governance as a Customer, Global, or Business Roles Administrator.

  2. Select Policy > Business Roles > Manage Inconsistencies.

  3. (Optional) Click the gear icon to customize the column display. For example, to view who started the inconsistency detection, select Started by in the Available Column list.

  4. To start inconsistency detection, click the refresh icon in the Action column.

  5. (Conditional) If there are 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 members of. It only looks for business role memberships that the user lost within the last N days. Identity Governance ignores business role memberships that were lost before N days.

  6. Click the number of detected inconsistencies to view the list of inconsistencies in a pop-up window.

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

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

    NOTE:Identity Governance assigns a color code for the inconsistency grant requests when they are submitted for fulfillment indicating pending requests from them with no inconsistencies. Similarly, when the requests are denied and the violations are cleared the color code is removed, which means inconsistencies are back.

  9. (Optional) Click the refresh icon to recalculate and update the number detected inconsistencies

  10. (Optional) Download one or more detected inconsistencies or all inconsistency detection results as a CSV file.

19.8.7 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 the number of memberships, authorizations, and auto-requests. You can enable the collection of more detailed information on the exact memberships, authorizations, and auto-requests that were generated during detection by setting the following configuration properties using the Identity Governance Configuration Utility. For more information about the utility procedures, see Using the Identity Governance Configuration Utility in the Identity Governance 4.2 Installation and Configuration Guide.

IMPORTANT:If you enable the collection of detailed information, business role detections slow down and consume more space in the database to store the detailed information. Generally, you should enable the collection of detailed information only if you are troubleshooting a 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 Customer, Global, or Business Roles Administrator.

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

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

  4. (Optional) Select the number of business roles 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.

You can click the settings icon to customize the columns displayed on the Business Roles Detection tab. For example, to add a column that displays the action that triggered each Business Role detection, click the settings icon, and then select Detection Triggered By.