23 Understanding SoD

23.2.1 Direct Provisioning

SoD check can be enabled in direct provisioning by performing the following steps:

1. Enable the SoD check system property. See "Enabling SoD" for information about the SoD check system property.

2. Set the Topology Name parameter in the connector IT resource. See step 2 of "Enabling SoD" for information about setting the Topology Name parameter.

3. Modify the connector provisioning workflow as described in "Modifying the Provisioning Workflow for SoD".

To directly provision a SoD-enabled resource:

1. Create a user whose account is to be created on the target system.

2. In the user details page of Oracle Identity Administration, go to the Resources tab, and click Add.

3. Select the SoD-enabled resource from the available options.

4. Enter the process form details. Parent process form must contain SoD check fields, such as SoDCheckStatus, SoDCheckTrackingID, SoDCheckResult, SoDCheckTimestamp, and SoDCheckEntitlementViolation. These fields are populated with values for SoD check.

5. Make sure that you provide entitlement in the child forms. Otherwise, SoD check will not be performed because SoD is required only to check for conflicting entitlements.

6. After provisioning has been initiated, you can see the account created on target system but no entitlement is provisioned. This is because entitlement tasks are kept in the Waiting status until the SoD check completes.

   In the resource profile, the Holder and SoDChecker tasks are in the Pending status and the SoDCheckStatus field in parent process form displays SoD Check Result Pending. The SoDCheckTrackingID field displays the tracking ID for the simulation started on the SoD engine.

7. Run the Get SOD Check Results Provisioning schedule job to get back results from the SoD engine and complete the SoD check.

8. If SoDCheckResult in the parent process form is in the Passed status, then there is no conflict and the entitlements are provisioned on the target system. The SoDCheckStatus field in the form displays SoD Check Completed, and the Holder and SoDChecker tasks are completed.

9. If SoDCheckResult in the parent process form is in the Failed status, then there is a conflict and the entitlements are not provisioned on the target system. The SoDCheckEntitlementViolation field in the form displays the conflicting policy on the SoD Engine, and the Holder task is canceled.

23.2.2 Updating Entitlements

Whenever you open the resource profile and try to add, update, or delete an entitlement in the child form, SoD check is triggered and the new Holder and SoDChecker tasks are generated. To complete SoD check, you must run the Get SOD Check Results Provisioning schedule job. If the new entitlement conflicts with the old ones, the new entitlement is not provisioned. Otherwise, the new entitlement is provisioned on the target system.

The addition, updation, and deletion of entitlements is done on a row by row basis. Therefore, for each modification, separate SoD check is triggered. If you make two modifications, then you can see two new SoDChecker tasks, one for each modification.

23.2.3 Request Provisioning

Default SoD check can be enabled in request provisioning by:

• Enabling the SoD Check system property

• Setting the Topology name parameter in the connector IT resource

• Request dataset must have an attribute of type IT Resource whose value is to be provided during request creation. A valid value must exist in its Topology Name parameter.

To create a request to provision a SoD-enabled resource:

1. In Oracle Identity Manager Advanced Administration, go to the Requests section, and click Create Request on the toolbar of the left pane. Select the Provision Resource request model.

2. Specify values for the attributes defined in the request dataset. The SoD check fields are part of the common dataset and is not displayed while creating the request. The fields can be viewed in the Request Details page after the request has been created.

3. Provide entitlement data as attribute values in the Create Request wizard, which displays the attribute names based on the request dataset. If no entitlements are provided, then SoD check will not start.

4. If SoD is successfully initiated, then the request is in Sod check result pending status. Check the SoD check field values in the request dataset. If SoD is not initiated successfully because of an error, then the request moves forward directly to the Obtaining Request Approval status. The SoDCheckStatus field in the dataset displays that Sod check is not initiated.

5. If the request is in Sod check result pending status, then run the Get SOD Check Results Approval schedule job to complete the SoD check, and move the request for approvals. If there is a conflict, then the SoDCheckResult field displays Failed status, and the SoDCheckEntitlementViolation field displays the violating duty.

6. Approve or reject the request-level approval from Oracle Identity Manager Self Service. For request-level approval, the default workflow is DefaultRequestApproval. Per this workflow, the approval task is assigned to the System Administrator role. If the administrator approves the request, then it goes for operational-level approval. By default, this level of approval is also assigned to the System Administrator role.

   The approver can approve or reject the request based on the SoD check result, as displayed in the request detail fields.

   After all approvals are obtained, the resource is provisioned on the target system.

23.2.4 Creating a Request to Modify Provisioned Resource

To request for modification of account on the target system:

1. In Oracle Identity Manager Advanced Administration, go to the Requests section, and click Create Request on the toolbar of the left pane. Select the Modify Provisioned Resource request model.

2. Select the resource to be modified and the user for which modification is required.

   The values for the attributes predefined in the request dataset are displayed. The SoD check fields are part of the common dataset and are not displayed while creating the request. The fields can be viewed in the Request Details page after the request has been created.

3. Add, update, or delete entitlement data as attribute values in the Create Request wizard, which displays the attribute names based on the request dataset.

4. If SoD is successfully initiated, then the request is in the SoD check result pending status. Check the SoD check field values in the request dataset. If SoD is not initiated successfully because of an error, then the request moves forward directly to the Obtaining Request Approval status. The SoDCheckStatus field in displays that SoD check is not initiated.

5. If the request is in the SoD check result pending status, then run the Get SOD Check Results Approval schedule job to complete the SoD check, and move the request for approvals. If there is a conflict, then the SoDCheckResult field displays Failed status, and the SoDCheckEntitlementViolation field displays the violating duty.

6. Approve or reject the request-level approval from the Self Service. For request-level approval, DefaultRequestApproval is the default workflow. Per this workflow, the approval task is assigned to the System Administrator role. If the administrator approves the request, then it goes for operational-level approval. By default, this level of approval is also assigned to System Administrator. The approver can approve or reject based on the SoD check result as displayed in the request detail fields.

   After all approvals are obtained, the new entitlements are provisioned, updated, or deleted on the target system.

23.2.5 Request Provisioning With the DefaultSODApproval Workflow

When the DefaultSODApproval workflow has been specified by using an approval policy, perform the following steps to request for provisioning:

1. Specify the DefaultSODApproval workflow at the operational level. Therefore, the steps before the operational level of approval remain the same.

2. When the request moves to operational level of approval, per the DefaultSODApproval workflow, the approval task is assigned to the System Administrators role. If the administrator approves this task, then the SoD check Web service is loaded, and SoD check is initiated.

   This can be confirmed by checking the request status, which must be SoD check result pending. Run the Get SOD Check Results Approval scheduled job to complete the SoD check.

3. An approval task is generated that is assigned to the SOD Administrators role. Any user having this role can claim the task and approve it.

4. Before approving the task, verify the SoD check results in the request details. If the task is approved, then the account and/or entitlement provisioning continues.

In this use case, SoD check is performed two times. First is the default SoD check before any level of approval, and the second one is initiated by the DefaultSODApproval workflow.

23.2.6 Request Provisioning with Approver-Only Field and With the DefaultSODApproval Workflow

If the IT resource field in the request dataset is made approver-only, then its value is not set when the request is created and can only be set by an approver. SoD check takes the SIL topology information from the connector IT resource. Therefore, if no resource has been selected, then SoD check is not triggered. Here, SoD check is not performed before any level of approval and only performed by using the DefaultSODApproval workflow after the approver has provided the IT resource information.

To request provisioning with approver-only field and with the DefaultSODApproval workflow:

1. When the request is submitted, it directly goes for request-level approval. There is no SoD check before this. Approver approves the request after providing the IT resource information.

2. When the request moves to the operational level of approval, per the DefaultSODApproval workflow, the approval task is assigned to the System Administrators role. If the administrator approves this task, then the SoD check Web service is invoked and SoD check is initiated. This can be confirmed by checking the request status, which must be Sod check result pending. You must run the Get SOD Check Results Approval schedule job to complete the SoD check.

3. An approval task is generated that is assigned to the SoD Administrators role. Any user having this role can claim the task and approve it.

4. Before approving the task, verify the SoD results in the request details. If task is approved, then the account and/or entitlement provisioning continues.

23.2.7 Requesting for Self

The user can raise a request for a resource or for modifying a resource from the Self Service. The steps for SoD check are similar for other resource provisioning use cases.

23.2.8 Provisioning Based on Access Policies

To perform provisioning based on access policies:

1. Create a new role.

2. Create an access policy to provision SoD-enabled resource to the new role. Make sure that you provide entitlements in the child form.

3. Assign this role to a newly created user. This provisions the account on the target system, but entitlement provisioning waits for SoD check.

4. Check the process form to verify the SoDCheckStatus field value. If the SoD check is successfully initiated, then the value of the SoDCheckStatus field is SoD Check Result Pending, and the Holder and SoDChecker tasks are generated, which are in the Pending status.

5. Run the Get SOD Check Results Provisioning scheduled job to complete the SoD check.

6. If the SoD check passes, then the Holder and SoDChecker tasks are completed and entitlements get provisioned. Otherwise, the Holder task is canceled and no entitlement provisioning takes place.

23.2.9 Updating Entitlements By Using Provisioning Based on Access Policies

To update entitlements by using provisioning based on access policies:

1. Create a new role.

2. Create an access policy to provision SoD-enabled resource to the new role. Make sure that you provide entitlements in the child form.

3. Assign this role to a user who already have SoD-enabled resource provisioned. Access policy only updates the entitlements for this account.

4. Check the new entitlement rows in the child process form. Check the parent process form to verify the SoDCheckStatus field value. If the SoD check is successfully initiated, then the value of the SoDCheckStatus field is SoD Check Result Pending, and the Holder and SoDChecker tasks are generated, which are in the Pending status.

5. Run the Get SOD Check Results Provisioning scheduled job to complete the SoD check.

6. If the SoD check passes, then the Holder and SoDChecker tasks are completed and entitlements get provisioned. Otherwise, the Holder task is canceled and no entitlement provisioning takes place.