Oracle® Fusion Middleware Developer's Guide for Oracle Identity Manager 11g Release 1 (11.1.1) E14309-04 |
|
![]() Previous |
![]() Next |
The concept of Segregation of Duties (SoD) is aimed at applying checks and balances on business processes. Each stage of a business process may require the involvement of more than one individual. An organization can convert this possibility into a requirement for all IT-enabled business processes by implementing SoD as part of its user provisioning solution. The overall benefit of SoD is the mitigation of risk arising from intentional or accidental misuse of an organization's resources.
In the Oracle Identity Manager implementation of SoD, IT privilege (entitlement) requests submitted by a user are checked and approved by an SoD engine and other users. Multiple levels of system and human checks can be introduced to ensure that even changes to the original request are vetted before the request is cleared. This preventive simulation approach helps identify and correct potentially conflicting assignment of entitlements to a user, before the requested entitlements are granted to the user.
This chapter contains the following sections:
The SoD Invocation Library (SIL) forms the basis of the SoD implementation in Oracle Identity Manager. The SIL is a collection of Java-based adapters that enable integration with predefined Oracle Identity Manager connectors. The connectors, in turn, link Oracle Identity Manager with the target systems. The following Oracle Identity Manager connectors are preconfigured for SoD validation:
The SIL also acts as the base for specialized adapters that integrate the SIL with SoD engines. These adapters are called SIL providers. A SIL provider acts as the interface between the SIL and a specific SoD engine. There are predefined SIL providers for the following SoD engines:
SIL Provider for SAP GRC
This provider is also known as the SAP GRC SIL Provider.. The certified versions of SAP GRC are versions 5.2 SP4 or later and 5.3 SP5 or later
SIL Provider for Oracle Application Access Controls Governor release 8.2.1 or later
This provider is also known as the OAACG SIL Provider.
Note: Contact Oracle Support for information about the latest patch set for Oracle Application Access Controls Governor. You must install the latest patch set before you start implementing and using SoD in Oracle Identity Manager. |
Figure 23-1 shows the architecture of SoD implementation in Oracle Identity Manager.
Figure 23-1 Architecture of SoD Implementation in Oracle Identity Manager
If required, you can configure any Oracle Identity Manager connector with either the SAP GRC SIL Provider or OAACG SIL Provider. For example, you can use the PeopleSoft User Management connector and the OAACG SIL Provider to automate SoD validation of requests for entitlements on PeopleSoft Enterprise Applications.
You can also create and use a SIL provider for a custom SoD engine, along with either one of the preconfigured Oracle Identity Manager connectors or an Oracle Identity Manager connector that you configure for SoD validation.
This section describes various use cases related to SoD:
Note: The procedures in this section are for Asynchronous SoD Engine, for example OAACG, for which you must run the scheduled job to complete the SoD check. |
Request Provisioning with Approver-Only Field and With the DefaultSODApproval Workflow
Updating Entitlements By Using Provisioning Based on Access Policies
SoD check can be enabled in direct provisioning by performing the following steps:
Enable the SoD check system property. See "Enabling SoD" for information about the SoD check system property.
Set the Topology Name parameter in the connector IT resource. See step 2 of "Enabling SoD" for information about setting the Topology Name parameter.
Modify the connector provisioning workflow as described in "Modifying the Provisioning Workflow for SoD".
To directly provision a SoD-enabled resource:
Create a user whose account is to be created on the target system.
In the user details page of Oracle Identity Administration, go to the Resources tab, and click Add.
Select the SoD-enabled resource from the available options.
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.
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.
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.
Run the Get SOD Check Results Provisioning schedule job to get back results from the SoD engine and complete the SoD check.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
To request for modification of account on the target system:
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.
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.
Add, update, or delete entitlement data as attribute values in the Create Request wizard, which displays the attribute names based on the request dataset.
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.
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.
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.
When the DefaultSODApproval workflow has been specified by using an approval policy, perform the following steps to request for provisioning:
Specify the DefaultSODApproval workflow at the operational level. Therefore, the steps before the operational level of approval remain the same.
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.
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.
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.
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:
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.
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.
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.
Before approving the task, verify the SoD results in the request details. If task is approved, then the account and/or entitlement provisioning continues.
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.
To perform provisioning based on access policies:
Create a new role.
Create an access policy to provision SoD-enabled resource to the new role. Make sure that you provide entitlements in the child form.
Assign this role to a newly created user. This provisions the account on the target system, but entitlement provisioning waits for SoD check.
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.
Run the Get SOD Check Results Provisioning scheduled job to complete the SoD check.
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.
To update entitlements by using provisioning based on access policies:
Create a new role.
Create an access policy to provision SoD-enabled resource to the new role. Make sure that you provide entitlements in the child form.
Assign this role to a user who already have SoD-enabled resource provisioned. Access policy only updates the entitlements for this account.
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.
Run the Get SOD Check Results Provisioning scheduled job to complete the SoD check.
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.