16.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. OpenText Identity Governance performs business role detections and evaluates business role membership changes to determine whether to issue the auto requests. During business role detection, OpenText Identity Governance only evaluates whether auto requests should be issued. After all business role detections including checking for pending requests, OpenText 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, OpenText 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, OpenText Identity Governance monitors when a user gains or loses an authorization, or when an authorization changes its auto-grant or auto-revoke policy. When OpenText 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 16-4 Business Role (Permissions and Applications) Automated Access Provisioning and Deprovisioning Process

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

  • OpenText 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.

  • OpenText Identity Governance auto-grants (makes) and/or auto-revokes (removes) a technical role assignment as needed. If OpenText 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 OpenText Identity Governance. However, if granting a technical role results in one or more potential SoD violations, OpenText Identity Governance sends the request through potential SoD violation approval first, as specified in the SoD approval policy.

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

The events that trigger OpenText Identity Governance to perform business role detections do not necessarily result in OpenText Identity Governance issuing auto-grant or auto-revoke requests. The rules that trigger a detection are different from the rules that govern whether OpenText 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 OpenText Identity Governance issuing the auto requests.

16.8.1 Understanding Business Role Detections

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

There are currently three types of business role detection:

All business roles

OpenText 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

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

Single business role

OpenText 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, OpenText 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, OpenText 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.

    Note that if a technical role is referenced by a business role, then OpenText Identity Governance will not allow you to delete or deactivate the technical role, unless the technical role is removed by the business role administrator from the list of all policies that references this technical role and prevents deactivation.

  • 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 OpenText 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 OpenText 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, OpenText Identity Governance schedules single-role detections for BR2 and BR3.

In phase two of detection, using the information collected in phase one, OpenText 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 16.8.2, Automatic Provisioning Requests. For specific conditions that could result in OpenText Identity Governance issuing auto-revoke requests, see Section 16.8.3, Automatic Deprovisioning Requests.

Some of the conditions that could result in OpenText 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 OpenText Identity Governance to compensate for in-progress requests. For more information about compensating requests, see Section 16.8.4, Managing Compensating Requests.

Although OpenText 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. For more information about inconsistencies and inconsistency detection and resolution policies, see Section 16.8.5, Understanding Inconsistency Detection and Resolution.

Depending on a variety of factors, business role detections can potentially take some time to complete. OpenText 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 16.8.8, Monitoring Business Role Detections.

After business roles are detected, OpenText 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.

16.8.2 Automatic Provisioning Requests

During phase one of business role detection, OpenText 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, OpenText Identity Governance evaluates what, if any, auto-grant requests to issue.

OpenText 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:OpenText 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, OpenText 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, OpenText 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 OpenText Identity Governance checking for completed and in-progress pending fulfillment requests do not apply in the case of making technical role assignments.

16.8.3 Automatic Deprovisioning Requests

During phase one of business role detection, OpenText 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, OpenText Identity Governance evaluates what, if any, auto-revoke requests to issue.

OpenText 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:OpenText 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, OpenText 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, OpenText 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, OpenText 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 OpenText 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. OpenText 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. OpenText 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 OpenText Identity Governance to evaluate whether it should issue an auto-revoke request to remove permission X from user A.

  6. OpenText 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.

16.8.4 Managing Compensating Requests

OpenText Identity Governance examines both the current state of the OpenText 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. OpenText Identity Governance compensates for pending fulfillment requests that would change whether the user has a resource. OpenText 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:OpenText 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 OpenText 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. OpenText 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 OpenText Identity Governance might issue a compensating request. The type of request indicates the OpenText 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:OpenText 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 OpenText 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 OpenText Identity Governance would issue compensating requests.

Scenario 1: User gains an auto request enabled permission that was lost but which OpenText 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. OpenText Identity Governance’s real-time identity collection detects this change and user A loses authorization for permission X.

  4. OpenText 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 OpenText Identity Governance catalog still shows that user A has permission X because no one executed collection and publication of that application since OpenText Identity Governance issued the revoke request. Therefore, OpenText 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 OpenText Identity Governance to issue compensating grant requests for this type of revoke request, OpenText 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 OpenText 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 OpenText Identity Governance detects this change and user A becomes a member of BR1 and gains an authorization for permission X.

  3. OpenText 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 OpenText Identity Governance catalog still shows that user A does not have permission X because no one executed collection and publication of that application since OpenText Identity Governance issued the grant request. Therefore, OpenText 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 OpenText Identity Governance to issue compensating revoke requests for this type of grant request, OpenText Identity Governance issues a compensating revoke request to remove permission X from User A.

16.8.5 Understanding Inconsistency Detection and Resolution

Although OpenText 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 OpenText Identity Governance issuing a request to do so. OpenText 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 detect and resolve inconsistencies manually or via policies. Administrators can:

  • Manually click on refresh icon in the Action column to start auto-grant and auto-revoke inconsistency detections and optionally resolve them from the Manage Inconsistencies tab on the Business Role page.

  • Create inconsistency resolution policies that automatically detect and resolve inconsistencies. Administrators can configure these policies to run on a schedule and also run them manually if needed from the Auto Resolution page.

Both methods, enable administrators to additionally:

  • Detect potential auto-grant and auto-revoke inconsistencies

    If a user has a resource that is auto-granted by a business role and there is a pending request to revoke the resource, OpenText Identity Governance flags the pending revoke request as a potential inconsistency. Likewise, if a user does not have a resource that is auto-revoked by a business role and there is a pending request to grant the resource, OpenText Identity Governance flags the pending grant request as a potential inconsistency. Checking for potential inconsistencies is enabled by default, but it might need more resources and might be expensive, so administrator might choose to disable potential inconsistency detections.

  • Use default (single complex query) or alternate (multiple simpler queries) algorithms for inconsistency detections

    Both algorithms result in the same number of detected inconsistencies, however, the elapsed time will differ based on the chosen algorithm. Administrators could monitor the performance using the two algorithms and choose the one that better meets their needs.

Though both methods support similar data monitoring and governance tasks, inconsistency resolution policies provide administrators greater flexibility in controlling what is automatically detected and resolved. When creating policies for inconsistency detection and resolution, administrators can select one or more inconsistency type to detect and resolve. Additionally, they can also configure specific rules to filter what is detected and resolved. For example, administrators could configure the policy to include or exclude potential inconsistency detection and not resolve inconsistencies if SoDs were not checked.

OpenText Identity Governance detects, resolves, and displays information about 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 inconsistencies were not detected, the count column will have a value of zero. Administrators can import and export policies and download the inconsistency detection results to a CSV file.

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, OpenText 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 OpenText 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. OpenText 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 OpenText 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 OpenText Identity Governance to do so.

  3. OpenText 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, OpenText Identity Governance triggers business role detection. However, OpenText 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, OpenText 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, OpenText 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 OpenText 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 OpenText Identity Governance detects the change. After it processes the change, OpenText Identity Governance triggers a business role detection. The detection causes OpenText 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 OpenText Identity Governance to do so.

  4. OpenText Identity Governance collects and publishes the application that contains permission X. After publication, business role detection is triggered. However, OpenText 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.

16.8.6 Creating Inconsistency Resolution Policies

Automatically checking for all inconsistencies and conflicts and establishing process authority during normal business role detection and resolving them might slow down the business role detection process. However, by creating inconsistency resolution policies, administrators can automatically detect and resolve inconsistencies based on specific business needs. When not sure how to define policies to optimize performance, administrators could first manually initiate inconsistency detections, download results, and analyze results, then define and schedule specific inconsistency policies based on the business needs.

To create policies, then monitor inconsistencies and resolutions:

  1. Log in to OpenText Identity Governance as a Customer or Global Administrator.

  2. Select Policy > Inconsistency Resolution.

  3. Click Plus icon to create a new policy

  4. (Optional) Enable policy to be activated when you save the policy details. If you choose not to activate the policy after saving the policy, you can later select Activate Policies from the Actions menu to activate the policy.

  5. Add name and description.

  6. Select Business Role Auto Grant/Revoke as the resolution type to detect and resolve inconsistencies in business role auto grants and revokes.

  7. On the Detection Settings tab, select inconsistency types and specify additional conditions and rules.

  8. On the Resolution Settings tab, select inconsistency types and specify additional conditions and rules.

  9. On the Schedule Settings tab, configure the auto-detection and resolution schedule.

  10. Save the policy.

  11. (Optional) Click Run Policy icon next to the name of the policy to manually run the policy for policy validation.

  12. (Optional) Click the gear icon to customize the column display. For example, to view last run time, select Last run time in the Available Column list.

  13. (Conditional) Once a policy has run automatically or was run manually, click Auto Resolutions tab.

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

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

  16. Click the number of resolved inconsistencies to view the list of resolved requests in a pop-up window.

    NOTE:OpenText 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.

  17. (Optional) Select the associated auto-resolution policy on the Auto Resolution Policies tab, then click Actions > Run Policies to recalculate and update the number detected and resolved inconsistencies

  18. (Optional) Download all or selected grant and revoke requests with inconsistency detection results as a CSV file.

16.8.7 Manually Detecting and Resolving Inconsistencies

OpenText Identity Governance allows an administrator to manually find inconsistencies and issue new requests to resolve them if needed. It is not a given that you should resolve all such inconsistencies, so OpenText Identity Governance provides an option to 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. If needed, administrators can download inconsistency results, analyze results, and select which inconsistency to resolve. Based on their analysis and authorization, they can provide inputs and optionally configure Inconsistency Resolution policies for automated inconsistency detections and resolutions.

To find and resolve inconsistencies manually:

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

  2. Select Policy > Business Roles > Manage Inconsistencies.

  3. (Optional) Enable use of alternate algorithm to use multiple queries instead of a single complex query.

  4. (Optional) Disable detection of potential inconsistencies.

  5. (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.

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

  7. (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, OpenText 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. OpenText Identity Governance ignores business role memberships that were lost before N days.

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

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

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

    NOTE:IOpenText 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.

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

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

16.8.8 Monitoring Business Role Detections

OpenText 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, OpenText Identity Governance stores the number of memberships, authorizations, and auto-requests. If you want to enable the collection of more detailed information on the exact memberships, authorizations, and auto-requests that were generated during detection, you can use the following configuration properties. Contact your SaaS Operations Administrator to configure these properties.

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 OpenText Identity Governance issued during the detection.

To monitor business role detections:

  1. Log in to OpenText 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.