Separation of duty approval workflow operation

After you create the policy, an approval workflow operation named approveSoDViolation for each violation is started during person operations. These operations might be role membership changes that cause separation of duty policy violations.

There is one separation of duty approval workflow that is called for all separation of duty violations. However, you can customize the workflow for individual policies to have multilevel approval, but the customizations must be done from within that one workflow.

To locate the approveSoDViolation approval operation, click Configure System > Manage Operations, and then select Global level. The approval operation is called for each violation that is found during the person operation (role membership change). You can modify this operation to include custom approval paths. For example, you can specify that both the policy owner and the user's manager approve the violation. By default, the policy owner is the approval participant. This image illustrates the approveSoDViolation approval operation.

After the approval participant approves the operation, the person operation is allowed to occur (implying approved) or fail (implying the approval was rejected). During the approval path, a violation exemption is recorded, noting who approved the exemption. The violation and exemption statistics are updated. You can view the exemption by clicking Manage Policies > Manage Separation of Duty Policies, and then clicking a number in the Exemptions column of the Separation of Duty Policies table.

When you request a change, such as adding a role to a user, a warning might be displayed. The warning indicates that the change can cause a separation of duty violation. The warning lists the policy and rule in violation. You can continue to submit the request or cancel the request. The warning is displayed in both the administrative console and the Self Service or the Identity Manager Service Center interface for the following requests:

Modifying or creating a person
Requesting an access
Modifying static role membership
Changing the role hierarchy

If you try to change role hierarchy in such a way that an existing separation of duty policy would become invalid, an error is displayed. The change does not occur. The error lists the policy and rule that would be in violation if the role hierarchy was modified as requested.

The audits of the exemption process occur automatically, depending on the result of the workflow. You do not need to manually call audit methods to have the audits recorded for use in the administrative console or reports.

However, you must set the process result with AA and process result detail with the string value that you want to audit as the justification for the exemption approval if the intent is to allow the violation to exist in the system. By default, the approval operation in the approveSoDViolation workflow has this PostScript code:

WorkflowRuntimeContext.setProcessResult(WorkflowRuntimeContext.getActivityResult());
WorkflowRuntimeContext.setProcessResultDetail(WorkflowRuntimeContext.getActivityResultDetail());

The first line in the PostScript code sets the process result to the same value as the result of the approval. AA indicates approved and AR indicates rejected. The second line sets the process result detail to the comments that were typed by the user when the approval to do activity was approved.

You can use normal workflow customizations to get the values you want, but be sure to call WorkflowRuntimeContext.setProcessResult() and WorkflowRuntimeContext.setProcessResultDetail() with some value if you want the system to treat the approval as an approved separation of duty exemption.

There might be multiple approvals in the workflow for separation of duty. The approver that is listed in the exemption record is the last person to approve an approval request in the workflow.