Access requests might cause new potential SoD violations or they might contribute to existing SoD violations. If approval is required for potential SoD violations (as specified in the SoD policy or through a global policy), the access request items that contribute to the potential SoD violation will not advance to their next phase (approval or fulfillment) until each potential SoD violation they contribute to has been either resolved or approved by the approvers in the SoD approval policy assigned to the violated SoD policy or SoD administrators.
When there is another request item contributing to the existing SoD violation, a potential SoD approval request will not be triggered even when the SoD or global policy requires approval. This is because the decision made for the existing SoD violation will automatically resolve the potential SoD violation. However, if you want every potential SoD violation to require approval regardless of existing SoD violations, contact your SaaS Operations Administrator to enable com.netiq.iac.sod.psodv.alwaysRequireApproval configuration property.
When potential SoD violations approval is required for access requests that have existing SoDs, then:
Current SoD violations that have been approved will take the new potential SOD approval control period when the associated potential SoD violation is approved, the request is fulfilled, and a collection and publication is performed.
Current SoD violations that are in a Not Reviewed state, will use the preapproval information for the last potential SoD violation approval and will be marked as approved.
Separate requests that create potential SoD violations will create multiple potential SoD violation approval tasks. When approving the SoD violation, Identity Governance will use the control period from the last approved potential SoD violation. Users can always change the control period in the SoD violation when the current approval expires.
If a potential SoD violation requires multiple approvers (as designated by an SoD approval policy configured to use the “four-eyes” principle), the violation is not approved until all specified approvers complete their respective approval steps. An approval step must be completed before Identity Governance notifies the approvers specified in the following approval step of their approval task. If an approver does not complete their SoD approval step by the expiration interval defined in the SoD approval policy, the approval step is assigned to the escalation approvers defined in the approval step.
NOTE:Any of the step approvers may resolve the violation as their step action.
All request items that contribute to the potential SoD violation must either be approved or denied to clear the potential violation. Denying request items might cause the potential SoD violation to be resolved. A potential SoD violation is considered to be resolved if it would no longer exist after denying one or more of the request items that contribute to it. No further action is required if a potential SoD violation is resolved.
If, on the other hand, the potential SoD violation still exists, and all approval steps are complete, the potential SoD violation is considered preapproved. Identity Governance will prompt the authorized approvers and administrators to provide the following information that will be used to automatically approve the actual SoD violation if the potential SoD violation becomes an actual SoD violation:
Preapproval expiration period. If the potential SoD violation is detected as an actual SoD violation within this period, the SoD violation will be automatically approved. If the SoD violation is detected after this period, it is not automatically approved and must be resolved or approved manually by the SoD policy owner or the SoD administrator.
NOTE:The actual SoD violation could be the result of someone fulfilling these specific requests, or because of other provisioning actions that were taken by users. Regardless of the reason, if the SoD violation occurs, preapproval will be given if the SoD violation occurred in the specified preapproval time period.
Reason for SoD approval. Justification for approving a potential SoD violation.
Approval control period (days). If the preapproved violation is detected before the expiration period, the violation will be approved for the number of days specified here. When there are multiple approvers, subsequent approvers in a potential SoD violation approval process can reduce the control period but cannot increase the previously-specified control period.
(Optional) Compensating Control. If compensating controls were specified in the SoD policy, the selection here indicates which compensating controls apply to the preapproval.
IMPORTANT:Identity Governance prevents preapproval of potential toxic SoD policy violations. For more information see Creating an SoD Approval Policy for Toxic SoD Violations.
NOTE:If an SoD policy changes its conditions, is deactivated, or is deleted, all potential SoD violation approval tasks associated with the SoD policy will be automatically finalized and submitted. Request items that were tentatively approved will be marked approved, items that were tentatively denied will be marked denied, and items where no decision was made will be marked as cleared. Items that were marked approved or cleared and were not associated with other potential SoD violation approval tasks will be advanced to their next phase (approval or fulfillment). For more information about viewing request status, see Section 23.2, Requesting Access.