22 Using Segregation of Duties (SoD)

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.

This chapter describes SoD in the following sections:

22.1 Understanding the SoD Validation Process

Oracle Identity Manager is a user provisioning solution with which entitlement requests can also be validated and managed. In the Oracle Identity Manager implementation of SoD, user requests for IT privileges (entitlements) are checked and approved by an SoD engine and other users. Multiple levels of system and human checks ensure that even changes to the original request are vetted before the request is cleared. This preventive approach helps identify and correct potentially conflicting entitlement assignments before the requested entitlements are assigned.

The SoD validation process in Oracle Identity Manager occurs when a user creates a request for an entitlement on a particular target system. The request is funneled through a resource approval workflow and, if it passes that initial workflow, a resource provisioning workflow.

  • The resource approval workflow is configured to validate requests in real time using an SoD engine. The SoD engine has predefined rules that are used to determine if the entitlement assignment would lead to SoD violations. The determination, once made, is returned to Oracle Identity Manager.

  • The resource provisioning workflow provisions an entitlement request that has passed the resource approval workflow on the target system.

If the user's request passes SoD validation (and an approver approves the request), the resource provisioning workflow is initiated. If the request fails SoD validation, the resource approval workflow can be configured to take remediation steps.

Note:

The resource provisioning workflow can be configured to perform the SoD validation again - immediately before the entitlement assignment is provisioned to the target system - to ensure SoD compliance.

Oracle Identity Manager communicates with both the SoD engine and the target system. In addition, the target system and SoD engine communicate with each other to enable the synchronization of entitlement data. Figure 22-1 shows the flow of data during the SoD validation process.

Figure 22-1 SoD Validation Process in Oracle Identity Manager

Description of Figure 22-1 follows
Description of "Figure 22-1 SoD Validation Process in Oracle Identity Manager"

22.2 Introducing the SoD Invocation Library

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 with adapters for SoD validation:

  • Oracle e-Business User Management release 9.1.0 and later

  • SAP User Management release 9.1.2.5 and later

    Note:

    With SAP UM 9.1.2.5, request entitlement does not work in Oracle Identity Manager 11g Release 2 (11.1.2.1.0).

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 (OAACG) release 8.6.3

    This provider is also known as the OAACG SIL Provider.

    Note:

    Install the latest patch set for OAACG before implementing and using SoD in Oracle Identity Manager. Contact Oracle Support for more information.

  • SIL Provider for Oracle Identity Analytics (OIA) 11g Release 1 Patch Set 1 Bundle Patch 2 (11.1.1.5.2)

    This provider is also known as the OIA SIL Provider.

    Note:

    You can download the current version of OIA from the My Oracle Support web site by navigating to the following URL and searching for Patch 13641335.

    https://support.oracle.com

Figure 22-2 shows the architecture of SoD implementation in Oracle Identity Manager.

Figure 22-2 Architecture of SoD Implementation in Oracle Identity Manager

Description of Figure 22-2 follows
Description of "Figure 22-2 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, the OAACG SIL Provider or the OIA 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.

22.3 Installing the SoD-enabled Connectors

Instructions to install the SoD-enabled connectors listed below can be found in the specific connector documentation. The Oracle Identity Manager Connectors Documentation page is located at the following URL:

https://download.oracle.com/docs/cd/E11223_01/index.htm

  • Oracle e-Business User Management release 9.1.0 and later

  • SAP User Management release 9.1.2.5 and later

22.4 Deploying the SIL and SIL Providers

SIL registration is provided by default for the some target systems and SoD engines. No deployment steps are required for these default combinations of target systems and SoD engines. Target systems for which SIL registration is provided include:

  • EBS and OAACG

  • PSFT and OAACG

  • SAP and SAP-GRC

  • OIA

    OIA SoD Engine synchronizes data with Oracle Identity Manager rather than any target system so the topology registered for OIA can be used with any connector configured with Oracle Identity Manager. OIA imports all data from Oracle Identity Manager. Therefore, from OIA perspective, Oracle Identity Manager is the target system.

You must perform the SIL registration process if you want to use any other combination of target systems or SoD engines. For more information, see Section 22.10, "Custom Combination of Target Systems and SoD Engines."

22.5 Configuring the SoD Engine

You must import entitlement data from the target system to the SoD engine. If required, you must also configure SoD validation rules on the SoD engine. The following sections provide these instructions for the preconfigured SoD engines.

22.5.1 Configuring Oracle Application Access Controls Governor

Configuring Oracle Application Access Controls Governor (OAACG) involves the following procedures:

Installing Oracle Application Access Controls Governor

OAACG 8.6.3.x is supported with Oracle Identity Manager 11g Release 2 (11.1.2.1.0) onward. First OAACG 8.6.3 GA must be installed. Further, this must be upgraded to OAACG to 8.6.3.6012 because Oracle Identity Manager SoD has been certified against OAACG 8.6.3.6012.

To install OAACG 8.6.3 GA:

  1. Logon to My Oracle Support.

  2. Click the Patches & Updates tab.

  3. Click Advanced Search.

  4. Select Product Family as Oracle Application Access Controls Governor and release as AACG 8.6.3. Select the appropriate platform, and click Search. The following patches and other latest ones are displayed:

    • 8.6.3 GA - 12724066 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3

    • 8.6.3.2000 - 12945100 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.2000 - Password protected and requires password from Support

    • 8.6.3.3000 - 12963883 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.3000 - Password protected and requires password from Support

    • 8.6.3.3500 - 12993066 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.3500 - Password protected and requires password from Support

    • 8.6.3.4000 - 13015405 ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.4000

    • 8.6.3.5000 - 13507234 ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.5000

    • 8.6.3.6000 - 13699560 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.6000

    • 8.6.3.6001 - 13872240 - ORACLE ENTERPRISE TRANSACTIONS CONTROLS GOVERNOR 8.6.3.6001

    • 8.6.3.6012 - 13931550 - ORACLE APPLICATION ACCESS CONTROLS GOVERNOR 8.6.3.6012

  5. Download patch 12724066.

  6. Perform the OAACG upgrade or install by referring to the OAACG install guide.

    Similarly, download patches for other required versions and apply in sequence. For each deployment, Access ETL must be re-run against the active data sources.

    OAACG 8.6.3GA must be upgraded to OAACG 8.6.3.6012. The sequence for upgrading is as follows:

    8.6.3GA to 8.6.3.4000 to 8.6.3.5000 to 8.6.3.6000 to 8.6.3.6001, and finally to 8.6.3.6012

    The patch IDs for downloading from Oracle Support for all these patches are mentioned in step 4.

Creating an Oracle Application Access Controls Governor Account for SoD Operations

Create an account of the Basic type for SoD validation operations. While performing the procedure described in "Creating an IT Resource to Hold Information about the SoD Engine", provide the user name and password of this account.

See Oracle Application Access Controls Governor documentation for information about creating the account.

Synchronizing Role and Responsibility Data from Oracle e-Business Suite to Oracle Application Access Controls Governor

You must import (synchronize) role and responsibility data from Oracle e-Business Suite into Oracle Application Access Controls Governor. After first-time synchronization, you must schedule periodic synchronization of data.

See Oracle Application Access Controls Governor documentation for more information.

Defining Access Policies in Oracle Application Access Controls Governor

After you import role and responsibility data, set up access policies in Oracle Application Access Controls Governor. These access policies are based on various combinations of roles and responsibilities.

See Oracle Application Access Controls Governor documentation for more information.

22.5.2 Configuring SAP GRC

SAP GRC uses user, role, and profile data from SAP R/3 to validate requests for accounts, roles, and responsibilities. Configuring SAP GRC involves the following procedures:

Creating an SAP GRC Account for SoD Operations

You must create an SAP GRC account for SoD operations. During SoD operations, this account is used to call the SAP GRC Web service.

When you create this user account, you must assign it to the following groups:

  • Everyone

  • Authenticated Users

You must not assign any roles to this account.

Generating the Keystore

To generate the keystore:

  1. In a Web browser, open the Web Services Navigator page of SAP GRC Access Control. The URL is similar to the following:

    https://SAP_GRC_HOST:PORT_NUMBER/VirsaCCRiskAnalysisService/Config1?wsdl

  2. Export the certificate.

  3. Copy the certificate into the bin directory inside the JDK installation directory of SAP GRC.

  4. Run the following command to create the keystore from the certificate file that you download:

    keytool -import -v -trustcacerts -alias sapgrc -file CERTIFICATE_FILENAME -keystore sgil.keystore -keypass changeit -storepass changeit

    Note:

    In this sample command, the keystore file name is sgil.keystore.

  5. When prompted for the keystore password, specify changeit. This is the default keystore password.

  6. When prompted to specify whether you want to trust the certificate, enter yes.

  7. The sgil.keystore file is created in the bin directory. Copy the file to the OIM_HOME/config directory.

Configuring the Risk Terminator

The Risk Terminator is a feature of GRC Access Control. It is the main component of the SoD validation functionality of SAP GRC. Whenever a role is created in the profile generator or assigned to a user, the Risk Terminator verifies if this role creation or assignment would result in an SoD violation.

See the Risk Terminator Configuration document for detailed information.

Synchronizing User, Role, and Profile Data from SAP ERP to SAP GRC

User, role, and profile data must be imported (synchronized) from SAP ERP into SAP GRC. After first-time synchronization, you must schedule periodic synchronization of data.

Defining Risk Policies in SAP GRC

After you import role and responsibility data, use the Risk Analysis and Remediation feature of SAP GRC to define risk policies of type Segregation of Duty.

See SAP GRC documentation for more information.

22.5.3 Configuring Oracle Identity Analytics

Configuring Oracle Identity Analytics involves the following procedures:

Note:

Oracle Identity Analytics 11.1.1.5.0 Patch Set 2 is certified for Oracle Identity Manager 11g Release 2 (11.1.2.1.0).

Creating an Oracle Identity Analytics Account for SoD Operations

Create an account on Oracle Identity Analytics and assign to it the SRM Admin role for SoD validation operations. When performing the procedure described in "Creating an IT Resource to Hold Information about the SoD Engine", provide the user name and password of this account.

See the Oracle Identity Analytics documentation for information about creating the account.

Oracle Identity Analytics 11.1.1.5.2 provides information on the entitlements that caused a conflict. This information is visible under SoD Details. The entitlements under SoD Details will be displayed in an encoded form (for example, 4~695~24123) because this is how policies are created on OIA.

Note:

The Oracle Identity Analytics Admin account with username rbacxadmin can also used.

Synchronizing Oracle Identity Manager Metadata With Oracle Identity Analytics

Import the resource metadata and resources from Oracle Identity Manager to Oracle Identity Analytics.

See the Oracle Identity Analytics documentation for more information.

Defining Identity Audit Policies in Oracle Identity Analytics

Set up identity audit rules and policies using Oracle Identity Analytics. Rules are created on the resource attributes. For entitlement SoD Check, give encoded values for roles and responsibilities as in Oracle Identity Manager.

See the Oracle Identity Analytics documentation for more information.

22.6 Enabling and Disabling SoD

The following sections contain information on enabling and disabling SoD.

22.6.1 Enabling SoD

To enable the SoD feature:

  1. Set the Segregation of Duties (SOD) Check Required system property to true. See "Managing System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about system properties.

  2. Set the topologyName parameter in the Connector IT Resource instance to the value present in SILConfig.xml. If you are using default SIL registration, set the topologyName parameter in connector IT Resource to one of the following:

    • sodoaacg if you are using the EBS connector and OAACG as the SoD engine

    • oaacgpsft if you are using the PSFT connector and OAACG as the SoD engine

    • sodgrc if you are using GRC as the SoD engine

    • sodoia if you are using OIA as the SoD engine

    Note:

    Connector IT resource must have the ALL USERS role so that any user is able to access the IT Resource information. This is required for SOD requests raised by users.

  3. Deploying SIL and SIL Providers

    To deploy SIL and SIL providers for default combination of target systems and SoD engines:

    1. Create a new IT Resource for Sod Engine with the name (type) as follows:

      • For EBS-OAACG: OAACG-ITRes (eBusiness Suite OAACG)

      • For SAP-GRC: GRC-ITRes (SoD Provider)

      • For OIA: IT resource with name OIA-ITRes (OIA) is predefined.

      • For PSFT-OAACG: IT resource with name PSFT-OAACG-ITRes(OAACG) is predefined.

    2. Edit the created IT Resource as described in "Creating an IT Resource to Hold Information about the SoD Engine".

      Note:

      • To configure with OAACG 8.5 or higher, add a new field to this IT resource with name as sodServerURL and value http(s)://HOST_NAME:PORT/URI, where URL is grcc/services/GrccService. For OAACG8.2.1, the value of URL is ags/services/AGService.

      • See "Managing System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about how to set system property values.

  4. Enabling SoD in Direct Provisioning and Access Policy Based Provisioning:

    SoD is enabled only if Holder and SODChecker tasks are present in the provisioning workflow.

    Enabling SoD in Request Provisioning:

    Steps 1 and 2 enables default SoD check in approval. The default SoD check is performed before the request goes for approval. If the SoD check is required after one level of approval, then default SoD check approval workflow, which is DefaultSODApproval, must be attached by creating an approval policy. SoD check can also be performed in any approval workflow on demand. This can be done by calling the SoD check Web service from BPEL. For more information, see "Modifying the Approval Workflow for SoD".

    Note:

    If DefaultSODApproval workflow is attached to operational level of approval, then the system administrator first needs to approve, and then only SoD Check is performed. After SoD Check is performed, approval is required by System Administrators. According to this workflow, first approval task is generated that is assigned to the system administrator, then SoD Check is performed, and then an approval task is generated. Any user who is a member of the System Administrators role can approve the second approval task after viewing the SoD Check results.

  5. Adding CSF Credentials for SoD Check:

    1. Login to the Enterprise Manager, and on the left tab, expand Weblogic Domain.

    2. Open base_domain.

    3. On top of the right pane, from the WebLogic Domain list, select Security, and then open Credentials.

    4. Select the Create Key option, and then select Map 'oim'.

    5. Provide the key as sodcheck.credentials, and select Type as Password.

    6. Provide Username as oiminternal and password as not used. Click OK to save the key.

22.6.2 Disabling SoD

You can disable SoD by performing any one of the following:

  • Set the Segregation of Duties (SOD) Check Required system property to false.

  • Remove the value of the topologyName parameter for the connector IT Resource so that its value is set to blank. If the topologyName parameter in ITResource is set to None, then SoD check is not performed.

Disabling SoD in Direct Provisioning and Access Policy Based Provisioning

Disable the Holder and SODChecker process tasks.

See Also:

The connector guide for detailed information about disabling these process tasks.

Disabling SoD in Request Provisioning

For disabling the default SoD check in approval, you can perform any one of the steps to disable SoD. If you want to perform the default SoD check in approval and only disable the SoD check in BPEL, then remove approval policy for SoD or remove call to SoD Check Web service from the approval workflow.

22.7 Enabling SSL Communication

The following sections contain information on enabling Secure Sockets Layer (SSL) communication for various SoD purposes.

22.7.1 Enabling SSL Between Oracle Application Access Controls Governor and Oracle Identity Manager

To enable SSL communication between Oracle Application Access Controls Governor and Oracle Identity Manager:

Note:

It is assumed that you have set sslEnable to true during the registration process.

  1. Export the certificate on the Oracle Application Access Controls Governor host computer as follows:

    Note:

    In Step 1, JAVA_HOME refers to the directory on the Oracle Application Access Controls Governor host computer.

    1. Run the following commands from the JAVA_HOME/bin directory:

      keytool -genkey -alias tomcat -keyalg RSA -keystore JAVA_HOME/lib/security/.keystore
keytool -certreq -alias tomcat -file JAVA_HOME/lib/security/xell.cvs -keystore JAVA_HOME/lib/security/.keystore
keytool -export -alias tomcat -file JAVA_HOME/lib/security/server.cert -keystore JAVA_HOME/lib/security/.keystore

      After you run these commands, the server certificate (server.cert) is created in the JAVA_HOME/lib/security directory.

    2. In the TOMCAT_HOME/conf/server.xml file, enter the details of the keystore as attributes of the Connector element. See the following example:

      <Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystoreFile="JAVA_HOME/lib/security/.keystore">

    3. Restart Oracle Application Access Controls Governor.

  2. Import the certificate on the Oracle Identity Manager host computer as follows:

    Note:

    In Step 2, JAVA_HOME refers to the directory on the Oracle Identity Manager host computer.

    1. Copy the server certificate created on the Oracle Application Access Controls Governor host computer to the JAVA_HOME/lib/security directory of the Oracle Identity Manager host computer.

    2. Run the following command from the JAVA_HOME/bin directory:

      keytool -import -alias oaacg_trusted_cert  -file JAVA_HOME/lib/security/server.cert -trustcacerts -keystore JAVA_HOME/lib/security/cacerts -storepass changeit

22.7.2 Enabling SSL Between SAP GRC and Oracle Identity Manager

To enable SSL communication between SAP GRC and Oracle Identity Manager export the certificate on the SAP GRC host computer as follows:

Note:

In this section, JAVA_HOME refers to the directory on the Oracle Identity Manager host computer that is used to run the application server.

  1. In a Web browser, open the Web Services Navigator page of SAP GRC Access Control. The URL is similar to the following:

    https://mysapserver01:50001/VirsaCCRiskAnalysisService/Config1?wsdl

  2. The next step depends on the browser that you are using:

    • On Microsoft Internet Explorer: In the Security Alert dialog box, click View Certificate. On the Details tab of the dialog box, use the Copy to file button to export the certificate.

    • On Mozilla Firefox: Export the certificate as a .pem file. To be able to perform this step, you might need to download and install the Certificate Viewer enhancement from the Mozilla Web site.

  3. Copy the certificate into the JAVA_HOME/lib/security directory used by the application server hosting Oracle Identity Manager.

  4. In a terminal window, change to the JAVA_HOME/bin directory.

  5. Run the following command to import the GRC certificate to cacerts:

    keytool -import -alias sapgrc_trusted_cert -file JAVA_HOME/lib/security/CERTIFICATE_FILENAME -trustcacerts -keystore JAVA_HOME/lib/security/cacerts -storepass changeit

    In this command:

    • CERTIFICATE_FILENAME is the name of certificate that has been exported from the SAP GRC host computer

    • The -storepass changeit clause specifies the password for the cacerts keystore.

  6. When prompted to specify whether or not you want to trust the certificate, enter yes.

    The "Certificate was added to keystore" message is displayed.

22.7.3 Calling SoD Check Web Service Over SSL

SOA calls the Oracle Identity Manager Web service over the URL given as the oimFrontEndURL, which is the URL used to access the Oracle Identity Manager UI, in the oim-config.xml file. By default, this is a HTTP URL. You can change this to HTTPS so that communication takes place over SSL. The SSL port for Oracle Identity Manager can be viewed on the WebLogic Administrative Console.

To call SoD check Web service over SSL:

  1. Locate the Oracle Identity Manager SSL port. To do so:

    1. Login to the WebLogic Administrative Console.

    2. Go to servers, oim_server1. You can see that SSL Listen Port is enabled.

  2. Change the oimFrontEndURL through the MBeans browser in Enterprise Manager. To do so:

    1. Login to Enterprise Manager.

    2. Go to oim_server1.

    3. From the list on the top of the page, select System Mbeans Browser.

    4. Go to Application Defined Mbeans, oracle.iam, Server: oim_server1, Application: oim, XMLConfig, Config, XMLConfig.DiscoveryConfig, and Discovery. The attributes are displayed to the right.

    5. Click oimFrontEndURL, and change its value, as shown:

      https://HOST_NAME:SSL_PORT

      Note:

      The value of oimFrontEndURL can also be set at the time of installing Oracle Identity Manager.

  3. Restart Oracle Identity Manager.

  4. Create a request for SoD-enabled resource. You can view the new workflow instance in Enterprise Manager. The Web service will be called on SSL port.

    Note:

    It is assumed that Oracle Identity Manager and SOA are running on the same Java Runtime Environment (JRE). If SOA and Oracle Identity Manager are running on different JREs, then WebLogic certificate exchange is required for SSL communication. For details, see Oracle WebLogic Server 10g Release 3 (10.3) documentation in the Oracle Technology Network (OTN) Web site by using the following URL:

    http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html

22.8 Configuring Workflows on Non SoD-enabled Connectors

Perform the procedures described in this section only if you are not using one of the preconfigured SoD-compatible connectors (Oracle e-Business User Management and SAP User Management). This section discusses the following procedures:

22.8.1 Modifying the Approval Workflow for SoD

To modify the approval workflow for SoD validation:

Note:

Forms are created from the UI based on the connector process form. Request dataset is no longer required in Oracle Identity Manager.

  1. In the IT resource of the connector, create the TopologyName parameter if it does not already exist. Figure 22-3 shows a sample IT resource in which this parameter has been added:

    Figure 22-3 The TopologyName Parameter

    Description of Figure 22-3 follows
    Description of "Figure 22-3 The TopologyName Parameter"

    If SoD Check property is set to true and topologyName parameter is set to the appropriate value in the connector IT Resource, then default SoD Check is performed in the preprocess stage of the approval workflow. After the request is created, the request status is changed to SoD check result pending for asynchronous SoD check and SoD check completed status for synchronous SoD check. For asynchronous SoD check, the Get SOD Check Results Approval scheduled job must be run to complete the SoD check.

    Note:

    If there is an error while performing SoD check, then the SoD Check Status attribute in the request dataset is set to SoD check completed with error and the request moves for approval. Final decision is on the approver whether or not to approve the request although SoD check is not performed successfully.

    Figure 22-4 shows the request history for asynchronous SOD check:

    Figure 22-4 Request History for Asynchronous SoD Check

    Description of Figure 22-4 follows
    Description of "Figure 22-4 Request History for Asynchronous SoD Check"

  2. In addition to the SoD check being triggered by default before any level of approval, it can be triggered by attaching the predefined DefaultSODApproval workflow. The workflow can be attached to the operational level of approval by creating an approval policy.

    Note:

    In Oracle Identity Manager 11g, patches were required on SOA and WebLogic Server to allow the SoD workflow to work. Currently, no patch is required for Oracle Identity Manager.

    For using the default workflow, see "Appying the Workflow By Using Approval Policy". This workflow contains an approval task that is assigned to the system administrator. After this approval task, a call is made to the SoDCheck Web service to return the SoD check result. The workflow with SoDCheck Web service call is shown in Figure 22-5.

    Note:

    There are three levels of approval for any request: template-level approval, request-level approval, and operational-level approval. DefaultSODApproval workflow must only be attached at the operational level. For bulk requests, the request-level approval is common for all resources and users. After this level of approval, separate requests are created for each combination of resource and user. The workflow performs SoD check separately for each resource and user at a time.

    The workflow is useful when SoD Check is required after request-level approval. One such instance is when the connector IT resource information is entered by the approver. Here, the IT Resource field in the request dataset is made approver-only, as shown below:

    <AttributeReference name="EBS Server" attr-ref="EBS Server" type="String" length="50" widget="itresource-lookup" available-in-bulk="true" itresource-type="eBusiness Suite UM" required="true" approver-only="true"/>

    In this example, the IT resource information is not available when the request is raised. It is available only after the approver enters it. If it is entered during request-level approval, then the DefaultSODApproval workflow can be used at operational level.

    Approval-only field is not supported in Oracle Identity Manager 11g Release 2 (11.1.2.1.0).

    Figure 22-5 Workflow with SoDCheck Web Service Call

    Description of Figure 22-5 follows
    Description of "Figure 22-5 Workflow with SoDCheck Web Service Call"

    After this, a switch case with approval tasks are assigned to the System Administrators role. Any user that has this role can claim the task and approve it. The switch is based on whether the SoD check result has passed or failed, as shown in Figure 22-6:

    Figure 22-6 Switch Case With Approval Tasks

    Description of Figure 22-6 follows
    Description of "Figure 22-6 Switch Case With Approval Tasks"

    Figure 22-7 shows the assignment of the approval task.

    Figure 22-7 Assignment of the Approval Task

    Description of Figure 22-7 follows
    Description of "Figure 22-7 Assignment of the Approval Task"

    Approval workflow has migrated to BPEL in Oracle Identity Manager 11g Release 2 (11.1.2.1.0), and therefore, you must use JDeveloper to view or modify the default workflows. The default SoD workflow is available in the OIM_HOME/workflows/composites/DefaultSODApproval.zip file. You can unzip this file and open the DefaultSODApproval.jpr in JDeveloper. In addition, you can create a new workflow by modifying any of the default approval workflows to call the SoD Check Web service and start SoD check on demand. To do so:

    Creating and Deploying Workflows on SOA 

    1. Create a new workflow project by running OIM_HOME/workflows/new-workflow/new_project.xml.

      Here:

      • WEBLOGIC_HOME is the directory on which Oracle WebLogic Server is installed.

      • NEW_PROJECT is the name of the new project that you want to create.

      To create the new workflow project, run the following command:

      ant -f new_project.xml

      This prompts for Project Name, Application Name, and Service Name for the new workflow name. Provide any name, such as SODWorkflow for all three. This creates a new project with the provided name in the workflows/new-workflow/process-template/ directory.

    2. Navigate to process-template/APPLICATION_NAME/PROJECT_NAME/ and open PROJECT_NAME.jpr from JDevepoler, where APPLICATION_NAME and PROJECT_NAME are the names of the application and project respectively.

      The PROJECT_NAME.jpr workflow is same as the DefaultRequestApproval workflow. You can modify this workflow to call the SoDCheck Web Service. Figure 22-8 shows the default workflow modified to perform SoD Check after human approval:

      Figure 22-8 Modified Workflow To Perform SoD Check

      Description of Figure 22-8 follows
      Description of "Figure 22-8 Modified Workflow To Perform SoD Check"

    3. Extract OIM_HOME/workflows/composites/DefaultSODApproval.zip and copy asyncsod.wsdl from the extracted directory to OIM_HOME/workflows/ process-template/APPLICATION_NAME/PROJECT_NAME/. Add a Web service, such as SODCheckService1, in the composite.xml and provide the asyncsod.wsdl as the WSDL file. The SoDCheck partner link is as shown in Figure 22-9:

      Note:

      BPEL connects to all external entities through a partner link.

      Figure 22-9 SoD Check Partner Link

      Description of Figure 22-9 follows
      Description of "Figure 22-9 SoD Check Partner Link"

    4. In the ApprovalProcess.bpel design, include the following BPEL activities:

      • ASSIGN: An assign activity must be added before calling the SoD Check Web Service. This activity initializes the parameters required to call the Web Service. To create an assign activity:

        i) Drag and drop the activity in the BPEL process opened in JDeveloper.

        ii) After the activity is created, double-click the activity, and click the Copy Operation tab.

        iii) Click Add, and then select Copy Operation. Provide the values for the variables, as shown in Table 22-1:

        Table 22-1 Variables to Assign

        Copy From Copy To

        XML Fragment

        <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
    <Address/>
</EndpointReference>

        Variable

        partnerlink

        Expression

        concat(substring-before(bpws:getVariableData('inputVariable','payload','/client:process/ns1:url'), "/workflowservice/CallbackService"), '/sodcheck/SoDCheckInitiateService')

        Partnerlink, EndpointReference, Address

        Variable

        partnerlink

        Partner Link

        SODCheckService1

        Variable

        Payload, RequestId

        Variable

        SODInvoke_initiate_InputVariable, where SODInvoke_initiate_InputVariable is the variable defined in Invoke BPEL Activity

        The following figures show the values to be added:

        Figure 22-10 shows the final assign activity:

        Figure 22-10 Final Assign Activity

        Description of Figure 22-10 follows
        Description of "Figure 22-10 Final Assign Activity"

      • INVOKE: The details for this activity are:

        Interaction Type: Partnerlink

        Partnerlink: SODCheckService

        Operation: Initiate

        Input Variable: SODInvoke_initiate_InputVariable

        Figure 22-11 shows the Invoke dialog box with sample values in the fields:

        Figure 22-11 The Invoke Dialog Box

        Description of Figure 22-11 follows
        Description of "Figure 22-11 The Invoke Dialog Box"

      • RECEIVE: The details for this activity are:

        Interaction Type: Partnerlink

        Partnerlink: SODCheckService

        Operation: Result

        Variable: SODResultReceive_result_InputVariable

        Figure 22-12 shows the Receive dialog box with sample values in the fields:

        Figure 22-12 The Receive Dialog Box

        Description of Figure 22-12 follows
        Description of "Figure 22-12 The Receive Dialog Box"

      • SWITCH: This activity is to switch between workflows based on SODCheck Result. The switch case is as shown in Figure 22-13:

      • New Human Tasks: A new human task may be created and assigned to an approver other then the system administrator. The new approval task is same as the old one already present in the workflow, except that the approver is different. This human task is used in the switch case. For example, if the SoD check passes, then the approval task can be assigned to a role. If the SoD check fails, then the approval task can be assigned to the System Administrators role. DefaultSODApproval always assigns approval task to the System Administrators role.

        Note:

        The SoDCheck Web service can be called multiple times.

    5. Applying SAML policy for request and callback for the AsyncSoD Web service:

      OWSM SAML token with Message Protection Policy, which is based on Security Assertion Markup Language (SAML), is used as security policy for message protection in asynchronous calls for SoD checks from the SOA composite to Oracle Identity Manager. In asynchronous SoD check Web service, it is mandatory to use SAML token with Message Protection Client Policy for Request and SAML token with Message Protection Service Policy for Callback, as described in this section.

      To apply SAML token with Message Protection Client policy for request:

      i) Right-click AsynchSoD Web service, and select Configure WS Policies, and then select For Request, as shown in Figure 22-14:

      Figure 22-14 Configuring WS Policies for Request

      Description of Figure 22-14 follows
      Description of "Figure 22-14 Configuring WS Policies for Request"

      ii) In the Configure SOA WS Policies dialog box, in the Security section, click the plus (+) icon to add a security policy.

      iii) In the Select Client Security Policies dialog box, select wss11_saml _token_with_message_protection_client_policy as shown in Figure 22-15, and then click OK.

      Figure 22-15 Select Client Security Policies

      Description of Figure 22-15 follows
      Description of "Figure 22-15 Select Client Security Policies"

      To apply SAML or Username token with Message Protection Service Policy for callback:

      i) Right-click AsynchSoD Web service, and select Configure WS Policies, and then select For Callback.

      ii) In the Configure SOA WS Policies dialog box, in the Security section, click the plus (+) icon to add a security policy.

      iii) In the Select Server Security Policies dialog box, select wss11_saml _or_username_token_with_message_protection_service_policy as shown in Figure 22-16, and then click OK.

      Figure 22-16 Select Server Security Policies

      Description of Figure 22-16 follows
      Description of "Figure 22-16 Select Server Security Policies"

    6. Compile the project to see if there are any errors. If there are no errors, then right-click the project, and select Deploy. In the dialog box that is displayed, select any one of the following options:

      • Deploy to Application Server: Select this option and then select the appropriate server. The workflow is directly deployed to the application server.

      • Deploy to JAR: A JAR file is created under the JDeveloper deploy directory with the name sca_PROJECT_NAME_rev1.0.jar, where PROJECT_NAME is the name of the project.

    7. From the SOA_HOME/bin/ directory, deploy the workflow on SOA server by running the following command:

      Note:

      • In this guide, SOA_HOME refers to the directory on which SOA server is installed.

      • Before running this command, ensure that the SOA server is running.

      ant -f ant-sca-deploy.xml -DserverURL=http://SOA_SERVER_HOSTNAME:SOA_PORT
-DsarLocation=JDeveloper/deploy/sca_PROJECT_NAME_rev1.0.jar -Duser=SOA_USER -Dpassword=SOA_PASSWORD

      Note:

      You must replace the following with valid values:

      • SOA_SERVER_HOSTNAME

      • SOA_PORT

      • PROJECT_NAME

      • SOA_USER

      • SOA_PASSWORD

      This deploys a new composite on SOA server. You can check if the composite is deployed by navigating to the following URL:

      http://SOA_SERVER_HOSTNAME:SOA_PORT/soa-infra

      In the URL, replace SOA_SERVER_HOSTNAME with the host name of the SOA server, and SOA_PORT with the port on which the SOA server is installed.

    8. Restart the SOA server.

      See Also:

      "Developing Workflows for Approval and Manual Provisioning" for general procedure for creating a new workflow

    Registering the Workflow 

    1. In the OIM_HOME/workflows/registration/ directory, create a NEW_PROJECT_NAME.props file by copying the DefaultRequestApproval.props. Modify the NEW_PROJECT_NAME.props by changing the name attribute.

      Here, NEW_PROJECT_NAME is the name of the new project that you created.

      The NEW_PROJECT_NAME.props file has the following contents:

      #This is is the input file for registering the default workflow
# <new project name>
name=NEW_PROJECT_NAME
category=Approval
providerType=BPEL
serviceName=RequestApprovalService
domainName=default
version=1.0
payLoadID=payload
operationID=process
listOfTasks=ApprovalTask

      Here,

      • The version parameter is the version of the workflow deployed on BPEL.

      • The listOfTasks parameter is the colon-seperated list of approval tasks. For example, if you add a new approval task as Approval_Task1, then you must provide ApprovalTask:ApprovalTask1 as the value for this parameter.

    2. Run OIM_HOME/workflows/registration /registerworkflows-mp.xml as shown:

      ant -f registerworkflows-mp.xml register

      This commands prompts for the following:

      UserName: Enter Oracle Identity Manager administrator user name.

      Password: Enter Oracle Identity Manager administrator Password

      oim server t3 URL: Enter t3://OIM_HOST_NAME/OIM_MANAGED_SERVER_PORT. Here, replace OIM_HOST_NAME with the host name of the computer on which Oracle Identity Manager is installed, and OIM_MANAGED_SERVER_PORT with the port on which Oracle Identity Manager is installed.

      inputpath (complete file name) of the property file: OIM_HOME/workflows/registration/NEW_PROJECT_NAME.props. Here, replace NEW_PROJECT_NAME with the name of the project that you created.

    Appying the Workflow By Using Approval Policy 

    1. Create approval policy for the request model to which you want to apply the SoD workflow. For example, if you want to perform SoD check while provisioning a resource, then create a policy for the Provision Resource request model. See "Creating Approval Policies" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for information about creating approval policies.

      Note:

      • Always attach SoD workflow at the operational level of approval because SoD is triggered separately for each resource.

      • Whether SoD Engine is asynchronous or synchronous, the SoD Check Web Service is always asynchronous and workflow modification remains the same for both.

22.8.2 Modifying the Provisioning Workflow for SoD

Each process definition has a process task attached to provision entitlements to a user. The SoD validation process must be performed before triggering this task and immediately after inserting all data in the child table that holds entitlements on the target system. Therefore, you must hold this process task until the SoD validation process is completed after inserting the data in child tables. To achieve this, you create a Holder task that precedes the provisioning of an entitlement to a user.

The Holder task is added to prevent provisioning of a resource to a user before the SoD validation process is completed. User entitlements are provisioned only if this task is complete. The task is completed when the SoD engine validates that SoD policies or rules are not violated by the assignment of the entitlements.

If an SoD validation process has been performed in approval workflow, then the SoD validation process need not be performed again even if the SoD validation process is enabled at the provisioning level. Whether the SoD validation process needs to be performed or not can be assessed by checking the following before the SoD validation process at the provisioning level:

  • Is the provisioning related to a request?

  • If yes, is the SoDCheckStatus field set to SoDCheckCompleted?

  • If yes, then do not perform the SoD validation process during entitlement provisioning.

Note:

The SoD validation process will be performed again only when the process child form is edited to add, update, or remove entitlements.

To modify the provisioning workflow for SoD validation:

  1. Add a Holder task to the provisioning workflow. This task must be made conditional and the Allow Multiple instances option must be selected.

    The following figure shows this Holder task:

    Description of holder1.gif follows
    Description of the illustration holder1.gif

  2. Make the connector insert, update, and revoke entitlement tasks dependent on the Holder task.

    The following figure shows all entitlement tasks of the Oracle e-Business User Management connector dependent on the Holder task:

    Description of holder2.gif follows
    Description of the illustration holder2.gif

    The following figure shows the Holder task as a preceding task of the Add Responsibility to User task:

    Description of holder3.gif follows
    Description of the illustration holder3.gif

  3. Add the SODChecker task (any task whose name starts with SODChecker). This task must be made conditional.

    The following figure shows the SODChecker task:

    Description of sodchecker_prov1.gif follows
    Description of the illustration sodchecker_prov1.gif

  4. Attach the InitiateSODCheck process task adapter to the SoDChecker task.

    Attach the following response codes to the SODChecker task:

    Response Code Task Status Description
    SODCheckResultPending P The SoD validation process is initiated and results are awaited.

    Note: This response code is for an SoD engine that returns responses asynchronously.
    SODCheckCompleted C The SoD validation process results have been returned, and the response shows that there is no SoD violation.
    SODCheckViolation C The SoD validation process results have been returned, and the response shows that there is an SoD violation.

    Note: For request provisioning of the EBS 9.1.0.7.0 resource with conflicting entitlements, the SodCheckViolation field in the process form is not updated. The entitlement violation is mapped to the field with the SoDCheckEntitlementViolation label, while the EBS resource has the field with the SoDCheckViolation label. Therefore, the mapping does not occur. Direct provisioning and provisioning through access policy successfully takes place with the SoDCheckViolation field label. To workaround this issue for request provisioning, change the SoDCheckViolation field label to SoDCheckEntitlementViolation in the EBS form by using the Design Console.

    Note: If the value is SoDCheckEntitlementViolation, then all types of provisioning, such as request, direct, and access policy, works fine. Therefore, you can keep the value as SoDCheckEntitlementViolation instead of changing the values.
    SODCheckNotInitiated C The SoD validation process has not been initiated because SoD has not been enabled in Oracle Identity Manager.

    The following figure shows these response codes:

    Description of sodchecker_prov2_.gif follows
    Description of the illustration sodchecker_prov2_.gif

22.9 Marking Child Process Form Tables That Hold Entitlement Data

Child process form tables can hold different types of multivalued data, for example, role data, profile data, and address information. You must mark the child process form tables holding entitlement data that you want to use for SoD operations. See "Marking Entitlement Attributes on Child Process Forms" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information.

This section contains the following topics:

22.9.1 Marking Request Dataset Attributes That Hold Entitlement Data

The request dataset attribute that holds the entitlement shall be marked with entitlement property set to true. Below is an example:

<AttributeReference name="Responsibility Name" attr-ref="Responsibility Name" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="true" entitlement="true">
                                        <lookupQuery lookup-query="select lkv_encoded as lkv_encoded,lkv_decoded as lkv_decoded from lkv lkv,lku lku where lkv.lku_key=lku.lku_key and
                        lku_type_string_key='Lookup.EBS.Responsibility' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0" display-field="lkv_decoded" save-field="lkv_encoded"/>
                                </AttributeReference>

22.9.2 Marking Child Process Form Tables That Hold Entitlement Data

Child process form tables can hold different types of multivalued data, for example, role data, profile data, and address information. You must mark the child process form tables holding entitlement data that you want to use for SoD operations. See "Marking Entitlement Attributes on Child Process Forms" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information.

22.10 Custom Combination of Target Systems and SoD Engines

This section contains the following topics:

22.10.1 Using a Custom Target System

Note:

Perform the procedure described in this section only if you want to use a target system other than Oracle e-Business Suite and SAP R3. You must also perform the procedures given in "Adding Custom SoD Engine" if you are using an SoD engine other than Oracle Application Access Controls Governor and SAP GRC.

You can perform this procedure either before or at any time after first-time implementation of SoD in Oracle Identity Manager.

The following is a summary of the procedure to configure the SIL for a new target system:

  1. Follow instructions given in the section "Addressing Prerequisites".

  2. Create Java class implementations of the IdMvsSoDDataTransformationOper interface for the connector. See "Creating the Transformation Layer" for instructions.

  3. Deploy the transformation service component. See "Deploying the Transformation Layer".

  4. Add entries in the registration XML file for the new target system. See "Modifying the Registration XML File" for instructions.

  5. Perform the procedure described in "Configuring Workflows on Non SoD-enabled Connectors".

  6. Mark child process forms that hold entitlement data. See "Marking Child Process Form Tables That Hold Entitlement Data" for instructions.

  7. Register the new target system. See "Registering the New Target System" for instructions.

22.10.1.1 Addressing Prerequisites

Ensure that the following prerequisites are addressed:

  1. Load entitlement data from the target system to the SoD engine.

    For details, see vendor documentation for the SoD engine.

  2. Deploy the Oracle Identity Manager connector for the target system. See the connector documentation for more information.

22.10.1.2 Creating the Transformation Layer

The transformation layer is used to transform target system attribute values into values that can be used by the SoD engine. The transformation layer is required to be created for any new SoD engine or target system type.

You must create the transformation layer as an implementation of the IdMvsSoDDataTransformationOper interface. Create implementations of the transformInput and transformSoDAnalysisInput methods in the implementation class of the IdMvsSoDDataTransformationOper interface.

See Also:

Oracle Fusion Middleware Java API Reference for Oracle Identity Manager for information about the implementation methods

In earlier releases of Oracle Identity Manager, the approval workflow data is read from the object forms. In Oracle Identity Manager 11g Release 2 (11.1.2.1.0), object forms are replaced by request datasets in the approval processes. As a result, the transformation layer must be changed so that entitlement data is read from the request dataset instead of object forms.

Transformation layer must also check the request model. If the request model is Provision Resource, then data must be read only from the request dataset. But if the request model is Modify Provisioned Resource, then data must be read both from the request dataset and process form.

22.10.1.3 Deploying the Transformation Layer

Transformation Service component is deployed as follows:

  1. Create a JAR file for the Java classes that you created for implementation of the IdMvsSoDDataTransformationOper service component type.

  2. Use the UploadJar utility to upload the JAR file as ThirdParty.

    Note:

    The UploadJar.sh or UploadJar.bat utility is in the OIM_HOME/bin/ directory. Run the utility from this location to upload the created JAR file to MDS.

22.10.1.4 Modifying the Registration XML File

Enter the details of the transformation layer in the registration.xml file as follows:

  1. Import the Registration.xml file from the MDS. The Registration.xml file is present with namespace /metadata/iam-features-sil/db/Registration.xml in MDS.

  2. Open the Registration.xml file in a text editor.

  3. Add the SystemType and ServiceComponent elements as shown in this block of XML lines:

    Note:

    Values that you must set are highlighted in bold. Guidelines and sample values are given after this block of XML.
            <SystemType name="SYSTEM_TYPE_NAME" type="Sod Source DataStore"></SystemType>
 
        <ServiceComponent type="IdMvsSoDDataTransformationOper" name="NAME_FOR_IMPLEMENTATION"
                <Impl-Class>NAME_OF_IPMLEMENTATION_CLASS</Impl-Class>
                <IdMSystemType>OIM</IdMSystemType>
                <SoDEngineType>SoD_ENGINE</SoDEngineType>
                <srcSystemType>SYSTEM_TYPE_NAME</srcSystemType>
 
              <DataTransformation>
                     <AttrSoD type="user" name="NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM"  sourceIdMAttrName="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE" isSourceKey="true"/>
                     <AttrSoD type="user" name="firstname"  sourceIdMAttrName="firstname" isSourceKey="false"/>
                     <AttrSoD type="user" name="lastname"  sourceIdMAttrName="lastname" isSourceKey="false"/>
                     <AttrSoD type="duty" dutyType="ENTITLEMENT_TYPE"  name="accessorigid"  sourceIdMAttrName="ENTITLEMENT_NAME" isSourceKey="true"/>
              </DataTransformation>

              <DataTransformation>
               . . .
              </DataTransformation>

              <DataTransformation>
               . . .
              </DataTransformation>
        </ServiceComponent>

    Apply the following guidelines while adding the SystemType and ServiceComponent elements in the registration.xml file:

    • Replace the placeholders with the following values:

      • SYSTEM_TYPE_NAME: Specify a name for the system type.

      • In the <SystemType> tag, type can have the SoD Source DataStore value for a custom target system, or SoD Engine as value for a custom SoD engine.

      • NAME_FOR_IMPLEMENTATION: Specify a name for the service component. For example: DBToOAACG

      • NAME_OF_IPMLEMENTATION_CLASS: Specify the name that you have set for the class that you create by performing the procedure described in "Creating the Transformation Layer". For example: oracle.iam.grc.sod.scomp.impl.oaacg.transformation.IdMvsSoDDataTransformationOperDBvsOAACG

      • SoD_ENGINE: Enter OAACG if you are using Oracle Application Access Controls Governor as the SoD engine. Enter GRC if you are using SAP GRC as the SoD engine. If you are using a custom SIL provider, then enter the name that you set for that SoD engine.

        See Also:

        "Adding Custom SoD Engine"

      • SYSTEM_TYPE_NAME: Specify the system type name that you entered earlier.

      • NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM: Specify the name of the attribute on the target system.

      • NAME_OF_ATTRIBUTE_ON_SOD_ENGINE: Specify the name of the corresponding attribute on the SoD engine.

      • ENTITLEMENT_TYPE: Enter the type of entitlement. For example: ROLE

      • ENTITLEMENT_NAME: Enter the name of one instance of the entitlement. For example: Resource Manager

    • Add one DataTransformation element for each attribute mapping that you want to create.

  4. Save and close the Registration.xml file.

  5. Export the Registration.xml file back to MDS.

22.10.1.5 Registering the New Target System

To register the new target system, perform the procedure described in the following sections:

22.10.1.5.1 Running the Registration Script and Providing Registration Information

The registration script (registration.sh and registration.bat) drives the registration process. When you run this script, it prompts you for the required information. The initial set of prompts displayed by the script are read from the registration.xml file. The registration script is in the OIM_HOME/bin directory. The registration.xml file is in the MDS.

Note:

  • Before running this utility, set APP_SERVER, OIM_ORACLE_HOME, JAVA_HOME, MW_HOME, WL_HOME, and DOMAIN_HOME.

  • You can run the registration script multiple times, at any time during the lifecycle of the Oracle Identity Manager installation. For example, you might want to register a new SoD engine. When you run the script, use the prompts to guide you to the section (set of prompts) in which you want provide input. You can skip the remaining sections.

    See Example 22-1 for a sample run of the registration script. In that example, it is assumed that an IT resource has been created to provide information about the SoD engine.

To run the script and provide registration information for the Oracle Identity Manager installation, SoD engine, and target system:

  1. Export the SILConfig.xml file from MDS. The SILConfig.xml file is present in MDS with namespace /metadata/iam-features-sil/db/SILConfig.xml.

  2. Open the SILConfig.xml file in a text editor and provide values for the DOMBuilderFactoryImpl element.

    The value of the DOMBuilderFactoryImpl element depends on the JRE that you are using:

    • If you are using the Sun JRE or Oracle JRockit JRE, then uncomment the DOMBuilderFactoryImpl element containing the following value:

      com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl

    • If you are using the IBM JRE, then uncomment the DOMBuilderFactoryImpl element containing the following value:

      org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

  3. In a command window, switch to the OIM_HOME/bin directory and run the registration script.

    Enter login information for Oracle Identity Manager. You are prompted to provide the values for Username, Password, and URL. The sample run segment is given below:

    [Enter the admin username:]OIM_ADMINISTRATOR_LOGIN
[Enter the admin password:]OIM_ADMINISTRATOR_PASSWORD
[Enter the service url:]t3://OIM_HOST_NAME:OIM_PORT_NO

    Specify valid values for:

    • OIM_ADMINISTRATOR_LOGIN

    • OIM_ADMINISTRATOR_PASSWORD

    • OIM_HOST_NAME

    • OIM_PORT_NO

    An example of the T3 URL is:

    t3://localhost:14000

    You are prompted to specify whether or not you want to proceed with registration:

    Do you want to proceed with registration? (y/n)

    Note:

    From this point onward, an explanation of each prompt displayed by the script is followed by the actual message of the prompt. The actual message is shown in monospace font in this document.

  4. Enter y to proceed with the registration. You are prompted to specify whether or not you want to register an Oracle Identity Manager installation:

    Register System Instance for type OIM?(y/n)

  5. Enter n.

    Note:

    From this point onward, the flow is specific to the registration of an Oracle e-Business Suite and Oracle Application Access Controls Governor installation. The flow is almost the same for the SAP R/3 and SAP GRC installation.

  6. You are prompted to specify whether or not you want to register an Oracle e-Business Suite installation:

    Register System Instance for type EBS? (y/n)

  7. Enter n if you want to use the existing Oracle e-Business Suite, which is registered by default. Enter y if you want to register a new EBS instance with another IT resource in Oracle Identity Manager.

  8. If you enter y, then you are prompted to enter an instance name for the Oracle e-Business Suite installation:

    Provide instance name

    Enter a name for the Oracle e-Business Suite installation. For example:

    ebs2

  9. You are prompted to specify whether or not you want to register an Oracle Application Access Controls Governor installation:

    Register System Instance for type OAACG? (y/n)

    Enter n if you want to use the existing OAACG, which is registered by default. Enter y if you want to register a new OAACG instance with another IT resource in Oracle Identity Manager.

  10. If you enter y, then you are prompted to enter an instance name for the Oracle Application Access Controls Governor installation:

    Provide instance name

    Enter a name for the Oracle Application Access Controls Governor installation. For example:

    oaacg01

  11. You are prompted to enter the name of the IT resource that you have created:

    OIM ITResource Instance Name:

    Enter the name of the IT resource that you created: OAACG ITR2

  12. If there are no more SoD components (system instances) to register, then enter n in response to the remaining prompts. Otherwise, similar steps to be followed for SAP and GRC instances. After this, you are prompted for custom System Type that you added in Registration.xml, say NEW.

    Register System Instance for type NEW? (y/n)

  13. Enter y. You are prompted to enter an instance name for the custom type, as shown:

    Provide instance name

  14. Enter a name for the installation, for example, new1. If the added system type is SoD Engine, then you are prompted to enter the name of the IT resource that you have created:

    OIM ITResource Instance Name:

  15. Enter the name of the IT resource that you created: ITR_NEW.

  16. Open the SILConfig.xml file in a text editor and provide values for the Topologies element. For information about topology values, refer to "Recording the Names of the System Types".

    The following block of XML shows the Topologies element and its child elements:

    Note:

    If you have multiple target system and SoD engine combinations, then you can add multiple Topology elements inside the Topologies element.
    <Topologies>
  <Topology>
   <name>@topologyName</name>
   <IdmId>@Idm RegistrationId</IdmId>
   <SodId>@Sod RegistrationId</SodId>
   <SDSId>@Sds RegistrationId</SDSId>                    
  </Topology>
</Topologies>

    Enter values for the following child elements of the Topologies element:

    • @topologyName: Enter a name for the topology.

      Note:

      Set the same name for the Topology element as the value of the TopologyName IT resource parameter.

    • @Idm RegistrationId: Enter the registration ID of the Oracle Identity Manager installation.

    • @Sod RegistrationId: Enter the registration ID of the SoD engine.

    • @Sds RegistrationId: Enter the registration ID of the target system.

      See Also:

      Step 2 in "Recording the Names of the System Types" for information about the child elements of the Topologies element.

  17. Export SILConfig.xml back to MDS.

Example 22-1 shows the output of a sample run of the registration script. Here, it is assumed that an IT resource has been created to provide information about the SoD engine.

Example 22-1 Sample Run of the Registration Script

sh registration.sh
Enter data related to login to OIM Server
[Enter the admin username:]OIM_ADMINISTRATOR_LOGIN
[Enter the admin password:]OIM_ADMINISTRATOR_PASSWORD
[Enter the service url:]t3://localhost:14000
Do you want to proceed with registration? (y/n)
y
Register System Instance for type OIM ?(y/n)
n
Register System Instance for type EBS ?(y/n)
n
Register System Instance for type OAACG ?(y/n)
n
Register System Instance for type SAP ?(y/n)
n
Register System Instance for type GRC ?(y/n)
n
Register System Instance for type NEW ?(y/n)
y
Provide instance name
new1
OIM ITResource Instance Name:
ITR_NEW
22.10.1.5.2 Recording the Names of the System Types

At the end of the registration process, the names of the system types are set in the Oracle Identity Manager database. You can retrieve these names from the database by using the registration script. After you retrieve these names, you must enter them in the SILConfig.xml file.

To retrieve and record the names of the service components:

  1. In a command window, switch to the following directory:

    OIM_HOME/bin/

  2. Run one the following commands:

    For Microsoft Windows:

    registration.bat printRegistrationIDs

    For UNIX:

    registration.sh printRegistrationIDs

    The following is sample output of this command:

    -----------------------------------------------
System Type     Instance Name  Registration ID
-----------------------------------------------
OIM                 oim                     1
EBS                 Ebs                     2
OAACG               oaacg                   3

  3. Copy these instance names for your reference.

22.10.2 Adding Custom SoD Engine

Note:

Perform the procedure described in this section only if you want to use an SoD engine other than Oracle Application Access Controls Governor and SAP GRC. You must also perform the procedures given in "Using a Custom Target System" if you are using a target system other than Oracle e-Business Suite and SAP R3.

You must install the SoD engine before you begin creating the SIL provider.

You can perform this procedure either before or at any time after first-time implementation of SoD in Oracle Identity Manager.

The following is a summary of the procedure to create a SIL provider:

  1. Follow instructions given in the section "Addressing Prerequisites".

  2. Create an IT resource to hold information about the SoD engine. See "Creating an IT Resource to Hold Information about the SoD Engine".

  3. Create Java class implementations of the interfaces for the SIL provider. See "Implementing the Service Components for the Provider" for instructions.

  4. Deploy the service components. See "Deploying the Service Components".

  5. Add entries in the registration XML file for the new SoD engine. See "Modifying the Registration XML File for the New SoD Engine" for instructions.

  6. Register the new SoD engine. See "Registering the New SIL Provider" for instructions.

22.10.2.1 Addressing Prerequisites

Ensure that the following prerequisites are addressed:

  1. Load entitlement data from the target system to the SOD engine. You can use any ETL utility to perform this step. For details, see vendor documentation for the SoD engine.

  2. On the SoD engine, create policy definitions or risk definitions by using the data loaded from the target system.

  3. Deploy the Oracle Identity Manager connector for the target system. See the connector documentation for more information.

22.10.2.2 Creating an IT Resource to Hold Information about the SoD Engine

You must create an IT resource to hold information about the SoD engine.

See Chapter 4, "Developing Application Instances" for detailed information about creating an IT resource type (if it does not already exist) and IT resource. You can specify any name for the IT resource type and IT resource. The following table specifies the names of the parameters that the IT resource must contain:

Parameter Description Sample Value
Source Datastore Name Enter the name of the source data store (the target system) that you defined in the SoD engine.

You specify a source data store name while performing the procedure described in the "Configuring Oracle Application Access Controls Governor" section.

 EBS STMD122
dbuser Enter the user name of the schema owner on the database used by the SoD engine.

This account is used to access the Application Access Controls Governor database during SoD operations.

Note: This parameter is specific to Oracle Application Access Controls Governor.

 databaseusr1
dbpassword Enter the password of the schema owner on the database used by the SoD engine.

Note: This parameter is specific to Oracle Application Access Controls Governor.

 Cryp100ne
jdbcURL Enter the JDBC URL for connecting to the database used by the SoD engine.

Note: This parameter is specific to Oracle Application Access Controls Governor.

 jdbc:oracle:thin:@10.123.123.123
password Enter the password of the account created on the SoD engine for API calls. K1rb1r0s
port Enter the number of the port at which the SoD engine is listening. 8090
server Enter the IP address of the host computer on which the SoD engine is running. 10.231.231.231
sslEnable Enter true if the SoD engine accepts only HTTPS communication requests. Otherwise, enter false. false
username Enter the user name of an account created on the SoD engine. This account is used to call the SoD engine APIs that are used during SoD validation. jdoe
sodServerURL Enter the URL of the SoD server, in the following format:

http(s)://HOST_NAME:PORT_NUMBER/URL

 http://10.231.231.231:8090/grcc/services/GrccService

Note:

If you want to use multiple SoD engines, then create multiple IT resources with the same IT resource type.

22.10.2.3 Implementing the Service Components for the Provider

Create Java implementations of the following service components:

See Also:

Oracle Fusion Middleware Java API Reference for Oracle Identity Manager

  • SoDAnalysisExecutionOper: The SoD analysis layer must be implemented for any custom SoD engine, which is not provided by default.

  • IdMvsSoDDataTransformationOper: Used to transform target system attribute values into values that can be used by the SoD engine. The transformation layer is required to be created for any new SoD engine or target system type.

  • CallBackIdMOper (optional): To be implemented if any callback is required from SoD Analysis Layer to access Oracle Identity Manager.

  • SoDDataValidationOper (optional): To be implemented to provide any validation on the attributes given in SoD Analysis layer.

22.10.2.4 Deploying the Service Components

Service components created in "Implementing the Service Components for the Provider" are deployed as follows:

  1. Create a JAR file for the Java classes that you created for Service Component implementation.

  2. Use the UploadJar utility to upload the JAR file as ThirdParty.

    Note:

    The UploadJar.sh or UploadJar.bat utility is in OIM_HOME/bin. Run the utility from this location to upload the created JAR file to MDS.

22.10.2.5 Modifying the Registration XML File for the New SoD Engine

Enter the details of the transformation layer in the Registration.xml file as follows:

  1. Import the Registration.xml file from the MDS. The Registration.xml file is present with namespace \metadata\iam-features-sil\db\Registration.xml in MDS.

  2. Open the Registration.xml file in a text editor.

  3. Add the SystemType element for the SoD engine, as shown:

    <SystemType name="SYSTEM_TYPE_NAME" type="SYSTEM_TYPE" isSynch="IS_SYNCH">
<!-- The Parameters which are required to connect the Sod Engine. -->
<Parameter name="PARAM_NAME1" required="true" />
<Parameter name="PARAM_NAME2" required="true" />
...
</SystemType>

    Here, replace:

    • SYSTEM_TYPE_NAME with a name for the system type.

    • SYSTEM_TYPE with SoD Engine.

    • IS_SYNCH with true or false, depending on whether the SoD engine is synchronous or asynchronous.

    • PARAM_NAME with the name of the parameter used to connect the SoD engine. These parameter values must be provided while registering the SoD engine. These are read in service component implementation classes to connect to the SoD engine.

  4. Add all implemented service components, as shown:

    <ServiceComponent type="SERVICECOMPONENT_TYPE" name="NAME_FOR_IMPLEMENTATION"
              <Impl-Class>NAME_OF_IPMLEMENTATION_CLASS</Impl-Class>
              <IdMSystemType>SYSTEM_TYPE_NAME_FOR_IDM</IdMSystemType>
              <SoDEngineType>SYSTEM_TYPE_NAME_FOR_SOD_ENGINE</SoDEngineType>
              <srcSystemType>SYSTEM_TYPE_NAME_FOR_TARGET_SYSTEM</srcSystemType>

<!-- AttrSoD tag is only required for Sod Analysis Service Component-->
<AttrSoD type="user" isKey="true" name="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE">
<!-- "name" attribute of the "Validation" element should be same as the "name" of one of the registered "ServiceComponent" of type "SoDDataValidationOper" -->
<Validation name="NAME_FOR_VALIDATION_ON_ATTRIBUTE"/>
</AttrSoD>

<AttrSoD type="duty" isKey="true" dutyType="ENTITLEMENT_TYPE" name="NAME_OF_ENTITLEMENT_ON_SOD_ENGINE"><Validation name="isNotNullOAACG"/>
</AttrSoD>

<AttrSoD...>
...
</AttrSoD>

<!-- DataTransformation tag is only required for transformation Service component-->
      <DataTransformation>
          <AttrSoD type="user" name="NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM"  sourceIdMAttrName="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE" isSourceKey="true"/>
          <AttrSoD type="user" name="firstname"  sourceIdMAttrName="firstname" isSourceKey="false"/>
          <AttrSoD type="user" name="lastname"  sourceIdMAttrName="lastname" isSourceKey="false"/>
          <AttrSoD type="duty" dutyType="ENTITLEMENT_TYPE"  name="accessorigid"  sourceIdMAttrName="ENTITLEMENT_NAME" isSourceKey="true"/>
      </DataTransformation>

</ServiceComponent>

    Here, replace:

    • SERVICECOMPONENT_TYPE: Can have values such as CallBackIdMOper, SoDAnalysisExecutionOper, SoDDataValidationOper, or IdMvsSoDDataTransformationOper depending upon the type of service component.

    • NAME_FOR_IMPLEMENTATION: Specify a name for the service component, for example, DBToOAACG.

    • NAME_OF_IPMLEMENTATION_CLASS: Specify the name that you have set for the class that you create by performing the procedure described in "Creating the Transformation Layer". For example: oracle.iam.grc.sod.scomp.impl.oaacg.transformation.IdMvsSoDDataTransformationOperDBvsOAACG.

    • SOD_ENGINE: Enter OAACG if you are using Oracle Application Access Controls Governor as the SoD engine. Enter GRC if you are using SAP GRC as the SoD engine. If you are using a custom SIL provider, then enter the name that you set for that SoD engine.

      See Also:

      "Adding Custom SoD Engine"

    • SYSTEM_TYPE_NAME: Specify the system type name that you entered earlier.

    • NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM: Specify the name of the attribute on the target system.

    • NAME_OF_ATTRIBUTE_ON_SOD_ENGINE: Specify the name of the corresponding attribute on the SoD engine.

    • ENTITLEMENT_TYPE: Enter the type of entitlement, for example, ROLE.

    • ENTITLEMENT_NAME: Enter the name of one instance of the entitlement, for example, Resource Manager.

  5. Save and close the Registration.xml file.

  6. Export the Registration.xml file back to MDS.

22.10.2.6 Registering the New SIL Provider

To register the new SIL provider, perform the procedure described in the following sections:

  1. See "Running the Registration Script and Providing Registration Information" for information on rerunning the registration script. In this run of the script, do not enter values for service components that have already been registered.

  2. See "Recording the Names of the System Types" for information on entering data about the new target system in the SILConfig.xml file.

22.11 Performing Role SoD Check with Oracle Identity Analytics

Role SoD Check is performed when a request to assign roles to, or revoke roles from, a user is raised. Role SoD Check with Oracle Identity Analytics is performed only when the request is raised; when roles are directly assigned or revoked, an SoD Check is not performed.

Note:

Integration between Oracle Identity Manager and Oracle Identity Analytics is a pre-requisite for performing an SoD Check with Oracle Identity Analytics.

22.11.1 Enabling Role SoD Check

To enable Role SoD Check with Oracle Identity Analytics, you need to do the following.

  1. Set the value of the XL.SoDCheckSystemProperty system property to TRUE. See "Managing System Properties" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about system properties.

  2. Set the value of the RoleSoDCheckTopologyName system property to sodoia. This topology is predefined and registered.

  3. Set OIA Connection Details in the 'OIA-ITRes' IT resource, as shown in the following figure:

    Description of oia_it_res.gif follows
    Description of the illustration oia_it_res.gif

22.11.2 Using Role SoD Check

The following sections describe how to implement the Role SoD functionality:

22.11.2.1 SoD Check When A User Requests a Role

The following steps are performed when a user raises a request for roles. SoD Check will be done if it has been enabled. This example procedure assumes that the user has already been assigned Role3.

Perform the following steps:

  1. Login to Oracle Identity Self Service as the user.

  2. Under My Profile, click My Access. Click the Roles tab, and then click Request Roles. The Catalog page is displayed where you can search for the role to be requested.

  3. Search for the specific role you want to assign to the user, for example ebsRole1.

  4. Click Add to Cart. This shows one item in the cart. Then, click Checkout.

  5. Click Submit to submit the request for the role. The request is created.

  6. Navigate to Requests, Track Requests.

  7. Search for the request that you created. Open the request to see the SoD Check results, as shown in the following figure:

    Description of role1.gif follows
    Description of the illustration role1.gif

  8. Click on the SoD Status to see the SoD Check result, as shown in the following figure:

    Description of role2.gif follows
    Description of the illustration role2.gif

    SoD Check result is Failed because the ebsRole1 role, for which request is raised, and Role3, which the user already had, are conflicting.

    The SoD Check result is available before request-level approval. Here, SoD Check has failed, but the administrator can approve the request to assign the conflicting role to the user.

22.11.2.2 SoD Check When A User Revokes a Role

This procedure assumes that the user has already been assigned the role being revoked.

Perform the following steps:

  1. Login to Oracle Identity Self Service as the user.

  2. Navigate to My Profile, My Access, and then click the Roles tab. The roles assigned to the user are displayed.

  3. Select the role to be removed, and then click Remove Roles. The Remove Roles page is displayed with the selected role as the cart item.

  4. Click Submit. The request is created.

    You can open the request details to see the SoD Check result, as shown in the following figure:

    Description of role3.gif follows
    Description of the illustration role3.gif

    The SoD Check result is now Passed because a conflicting role has been removed.

22.11.2.3 SoD Check When an Administrator Requests To Assign Roles

This procedure allows the system administrator to assign a role to the user.

  1. Login to Oracle Identity Self Service as the System Administrator.

  2. Navigate to Administration, Users, search for users, and then open the details of the selected user.

  3. Click the Roles tab, and then click Request Roles. The Catalog page is displayed.

  4. Search for the ebsRole1 and Role3 roles, and add them to the cart. Click Checkout. The cart details is displayed, as shown in the following figure:

    Description of role5.gif follows
    Description of the illustration role5.gif

  5. Click Submit. A request is created. Because this is a bulk request, SoD Check is not initiated for it.

  6. Login to Oracle Identity Self Service as the system administrator, and navigate to Requests, Pending Approvals, and then approve the request. Two child requests are created and SoD Check is performed for each child request.

  7. Navigate to Track Requests, and open each child request to see the SoD details. The following figure shows the SoD details for the request created for ebsRole1 role:

    Description of role6.gif follows
    Description of the illustration role6.gif

    The following figure shows the SoD details for the request created for the Role3 role:

    Description of role7.gif follows
    Description of the illustration role7.gif

22.11.2.4 SoD Check When an Administrator Requests To Revoke Roles

This procedure allows the system administrator to revoke a role from the user:

  1. Login to Oracle Identity Self Service as the system administrator.

  2. Navigate to Administration, Users, search for users, and then open the details of the selected user.

  3. Click the Roles tab, select the roles to be removed, and then click Remove Role.

    Note:

    A request is created to remove more then one role. For a single role, no request is created, and therefore, no SoD Check is performed.

  4. On the Remove Roles page, click Submit. A request is created.

  5. Approve the request. Two requests are created and SoD Check is performed for each request. The following figure shows the SoD Check result for the request created for the ebsRole1 role:

    Description of role8.gif follows
    Description of the illustration role8.gif

    The following figure shows the SoD Check result for the request created for the Role3 role:

    Description of role9.gif follows
    Description of the illustration role9.gif

    Because the request is raised by the System Administrator and there is no SoD Conflict, both the child requests are approved by default.

    Note:

    By default, operational-level approval is triggered for requests that are raised by the System Administrator only if the SoD Check result is Failed because a conflict is detected.

22.12 Using SoD in Provisioning Workflow

This section describes various use cases related to SoD:

Note:

The procedures in this section are for Synchronous SoD Engine, for example OAACG, for which you do not need to run the scheduled job to complete the SoD check.

22.12.1 Provisioning Application Instance With Child Data

To provision an application instance as the system administrator:

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

  2. On the User Details page, click the Accounts tab, and click Request Accounts. The Catalog page is displayed.

  3. Search for the application instance, for example EBS.

  4. Add the application instance to cart, and checkout.

    The form that is added to the application instance is displayed on the Cart Details page. This form contains the default SoD check fields, such as SoDCheckStatus, SoDCheckTrackingID, SoDCheckResult, SoDCheckTimestamp, and SoDCheckEntitlementViolation. These fields are populated with values for SoD check.

  5. Provide the required details in the form. 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. Click Ready to Submit, and then submit the request. Because this a request for a single user for a single application instance, no request is created and the application instance is directly assigned to the user.

    Because synchronous SoD Check has happened, you can see the SoD Check result on the Account Details page. If you select conflicting entitlements, then the SoD Check will fail and the entitlements will not get provisioned on the target system. Figure 22-17 shows the SoD Check Result.

    Figure 22-17 Conflicting Entitlements

    Description of Figure 22-17 follows
    Description of "Figure 22-17 Conflicting Entitlements"

    If you open the resource history, the Holder task is displayed in Canceled state because SoD Check resulted in a conflict. In addition, the SoDChecker task is in Completed state indicating that SoD Check has completed. Figure 22-18 shows the resource provisioning details.

    Figure 22-18 Resource Provisioning Details

    Description of Figure 22-18 follows
    Description of "Figure 22-18 Resource Provisioning Details"

If the steps to provision an application instance are performed by a user with viewer admin role, a request is created. SoD Check result is visible in this request. Approver has the authority to approve or reject the request after seeing the SoD Check result. Figure 22-19 shows the SoD Check result in request details:

Figure 22-19 SoD Check Result in Request Details

Description of Figure 22-19 follows
Description of "Figure 22-19 SoD Check Result in Request Details"

22.12.2 Modifying Application Instance to Add or Delete Child Data

Whenever you open the user details, select an already provisioned account, and try to modify it by adding, updating, or deleting an entitlement in the child form, SoD check is triggered. If this operation is performed by the system administrator, new Holder and SoDChecker tasks are generated. If the new entitlement conflicts with the old ones, then the new entitlement is not provisioned. Otherwise, the new entitlement is provisioned on the target system.

If the operation is performed by the user with view admin role, a new request for modifying application instance is created. SoD Check result can be seen in this request.

22.12.3 Provisioning Entitlements to a User

Entitlements are first level entities in Oracle Identity Manager. Therefore, entitlements can be directly requested, as follows:

  • System Administrator requests for a single entitlement for a user: The SoD Check is done and entitlement is granted to the user if it does not conflict with any of the existing entitlements. SoD Check results can be seen in the Account Details page. The Holder and SoDChecker tasks are created for performing the SoD Check.

  • System Administrator requests for multiple entitlements: For bulk operation, requests are created. Therefore, if the system administrator requests for two entitlements, then a request r1 is created. SoD Check is always done at the child request level, and therefore, no SoD Check is done for r1. After the request-level approval is obtained for r1, two child requests r2 and r3 are created. SoD Check is done for both the child requests. Result can be seen in the Request Details.

  • User requests for single entitlement: This results in a request being created because the user cannot directly get the entitlement. An approver must approve it. SoD Check is done for the request. No Holder or SODChecker tasks are created.

22.12.4 Revoking Entitlements From a User

Revoke entitlement use cases are similar to provisioning entitlements, as described in "Provisioning Entitlements to a User". When the last entitlement is revoked from the user, no SoD Check is done because the user does not have any entitlements.

22.12.5 Requesting for Roles and Entitlements

Oracle Identity Manager supports heterogeneous requests that allow you to request for roles along with entitlements. To do so, open the Catalog page, search for the required entities, select the entities, and submit. This result in the creation of a request. When this request is approved, child requests are created for the requested entities. SoD Check is done for each of these child requests. Roles and entitlements are sent for separate SoD Checks.

Note:

SoD Check conflict is not detected between roles and target system entitlements. If request is raised for the two, they go through separate SoD Checks.

22.12.6 Requesting for Roles and Application Instances With Child Data

This is similar to requesting for roles and entitlements, as described in "Requesting for Roles and Entitlements". Separate SoD Check is done for application instance and role.

22.12.7 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 completed.

  3. An approval task is generated that is again assigned to the System Administrator.

  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.

22.12.8 Requesting for Role With an Access Policy Attached

If the role is requested by a user and the request is for multiple roles, then SoD Check is first be done for the roles. After the request is approved and the role is assigned to the user, run the Evaluate User Policies schedule job to evaluate the access policy. Then, account provisioning is triggered. This again results in SoD Check for the account being provisioned if child data is requested for. SoD Check result can be seen in the Account Details page. If account is provisioned without child data, then no SoD Check is done.

Note:

See "Predefined Scheduled Tasks" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager the for information about the Evaluate User Policies schedule job.

22.12.9 Provisioning Based on Access Policies Without Approval

To perform provisioning based on access policies:

  1. Create a new role.

  2. Create an access policy (without approval) 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. Run the Evaluate User Policies scheduled job to trigger the access policy and provision the account on the target system. But entitlement provisioning will wait for SoD check.

  4. Check the Account Details to verify the SoDCheckStatus field value. If the SoD check is successfully completed, then the value of the SoDCheckStatus field is SoD Check Completed, and the SoDChecker task will be in Completed state.

    The Holder task status depends on the SoD Check result. If the SoD check passes, then the Holder task is completed and entitlements are provisioned. Otherwise, the Holder task is canceled and no entitlement provisioning takes place.

22.12.10 Provisioning Based on Access Policies With Approval

When an access policy is created with approval, request is created for account provisioning. After the role is assigned to the user and the Evaluate User Policies schedule job is run, a request is created to provision account to the user. SoD Check is done for this request.

22.12.11 Requesting for Entitlements From Two Application Instances

A request can be raised for two entitlements from different application instances, one for which Sod Check is enabled and other for which it is not enabled. Here, SoD Check is performed for the entitlement for which SoD Check is enabled.

Note:

SoD Check is not supported between entitlements from different application instances. For example, SoD Check is not supported between an EBS and a PSFT entitlement.

22.13 Enabling Logging for SoD-Related Events

If you want to enable logging for all SoD-related events

  1. In a text editor, open the DOMAIN_HOME/config/fmwconfig/servers/oim_server1/logging.xml file.

  2. Search for the <loggers> element. The following is a sample <loggers> element:

    <loggers>
<logger name="" level="WARNING:1">
<handler name="odl-handler"/>
<handler name="wls-domain"/>
<handler name="console-handler"/>
</logger>

    You can change the logging level to INCIDENT_ERROR:1, ERROR:1, NOTIFICATION:1, NOTIFICATION:16, TRACE:1, TRACE:16, or TRACE:32. The default logging level prints the error and warning messages.

22.14 Troubleshooting SoD Check

Table 22-2 lists the troubleshooting steps that you can perform if you encounter errors while performing SoD check.

Table 22-2 Troubleshooting SoD Check

Problem Solution

The SoDCheckStatus field in the process form displays no value or default value. For the field in EBS connector, SoD Check not initiated is the default value . Also, the SoDCheckResult field is not populated.

This means that SoD configuration is incorrect. Check if the Segregation of Duties (SOD) Check Required system property is set to true. If yes, then check the value of topologyName in connector IT resource field.

If default registration is used, then the value of the topologyName parameter is sodoaacg for OAACG SoD engine and sodgrc for SAP GRC. If registration is done manually, then check if the corresponding topology is defined in the SILConfig.xml file and this file is seeded into MDS after the change.

The SoDCheckStatus field in the process form or request dataset displays Sod check completed with error.

The SoDCheckResult field displays Error from SoD Engine.

SoD configuration is correct but SoD engine connection information might be incorrect, or there is an error from the SoD engine. Errors from the SoD engine can occur because of the following reasons:

  • SoD engine or its corresponding database is down.

  • SoD engine is not completely synchronized with the target system. Therefore, specific entitlements for which SoD check is initiated may not be present on the SoD engine.

Check the SoD engine log for further errors. If no tracking ID is returned by the SoD engine, then simulation is not started successfully.

The SoDCheckStatus field in the process form is in the SoD Result Pending status, and does not move to the SoD Check Completed status even on running the scheduled job.

Make sure that you run the Get SoD Check Results Provisioning scheduled job and not the scheduled job for approval. Make sure that the scheduled job is triggered. You may enable logging at DEBUG level to confirm this.

If the scheduled job is run and the SoD check is still not completing, then there must be an error from the SoD engine. Check the SoD engine log for details.

When requesting for SoD-enabled resource, no SoD fields are displayed in the dataset after creating the request, and the request directly moves to the request-level approval.

This error means that SoD configuration is incorrect. Check if the Segregation of Duties (SOD) Check Required system property is set to true. If yes, then check the value of topologyName in the connector IT resource field.

If default registration is used, then the value of the topologyName parameter must be sodoaacg for the OAACG SoD engine and sodgrc for SAP GRC.

If registration is performed manually, then check if the corresponding topology is defined in the SILConfig.xml file and this file is seeded into MDS after the change.

The SoDCheckStatus field in the request dataset stays in the SoD Result Pending status and does not move to the SoD Check Completed status even on running the scheduled job.

Make sure that you run the Get SoD Check Results Approval scheduled job and not the scheduled job for approval. Make sure that the scheduled job is triggered. You may enable logging at DEBUG level to confirm this.

If the scheduled job is run and the SoD check is still not completing, then there must be an error from the SoD engine. Check the SoD engine log for details.

The SoD check is successfully performed during request provisioning, but the resource state in the user profile does not display as Provisioned. Therefore, the request is in the Operation Initiated status.

Check the process tasks in the resource history. If only the System Validation task is displayed, then the required data might not have been saved in the form. You can try saving the form manually by opening the form in edit mode and clicking Save. Enable the Auto-save option in the process definition for future requests.

If other tasks, such as the task to create an account on the target system, are displayed in the resource history, then check the task details to verify if there is an error from the target system. For example, the account being created already exists on the target system.

The SoD check is successfully performed during direct provisioning, but the resource state in the user profile is not Provisioned.

Check the process tasks in the resource history. If only the System Validation task is displayed, then the required data might not have been saved in the form. This can happen if the Auto-Save option is on in the process definition, and therefore, the form is not displayed during direct provisioning. You can try saving the form manually by opening the form in edit mode and clicking Save. Disable the Auto-save option in the process definition for future requests.

If other tasks, such as the task to create an account on the target system, are displayed in the resource history, then check the task details to verify if there is an error from the target system. For example, the account being created already exists on the target system.

Request provisioning has been successfully done and appropriate values are displayed in the request dataset, but the SoD status and result are not reflected to the process form.

Check the SoD field labels in the process form. They must be SoDCheckStatus, SoDCheckTrackingID, SoDCheckResult, SoDCheckTimestamp, and SoDCheckEntitlementViolation. If you change these field labels, then SoD field will not be mapped from the request dataset to the process form.

A particular SoD request is being tried several times and generating error.

There may be a problem with the SoD configuration or error in data submitted in a particular request. If you see that the traces of error for a request though SoD configuration is correct and you want to ignore the particular request, then you can prevent the JMS message related to the request from being tried multiple times by changing the Redelivery Limit for the OIMSODQueue from the WebLogic Administrative Console. To do so:

  1. Login to the WebLogic Administrative Console.

  2. Go to Services, Messaging, JMS Modules, and OIMJMSModule. The list of all the queues are displayed.

  3. Click oimSODQueue, and then click Delivery Failure.

  4. Change the value of Redelivery Limit from -1 to a positive value. This determines how many times a SoD JMS message will be retried.

Error in task assignment rules evaluation. Error in task assignment rules evaluation for user null. The error is Error in getting owners for "{0}" in configuration "{1}". Error occurred in getting owners for "SOD ADMINISTRATORS" in configuration "jazn.com". Ensure that the group name is valid and has associated owners. Contact Oracle Support if error is not fixable. Make sure that the rules specified for user null are valid.

Ignore this error. The reason for this error is that the OIMDBProvider does not support getting owners for a role. Therefore, SOA logs this error.

When trying to perform SoD check by using the DefaultSODApproval workflow, the following error message is displayed:

Unknown Credential type to find the password for the given map : oim key : sodcheck.credentials

Add sodcheck.credentials as described in step 5 of "Enabling SoD".

The following error is displayed:

[exec] Caused By: Thor.API.Exceptions.tcITResourceNotFoundException
[exec] at com.thortech.xl.ejb.beansimpl.tcITResourceInstanceOperationsBean.getITResourceInstanceParametersData

The SoD Engine IT resource has not been created. Therefore, according to the SoD Engine that is to be used, the corresponding IT resource must be created. For example, for OAACG, create OAACG-ITRes.

If SoD is enabled for more than one SoD Engine, for example OAACG and OIA, and you try to start SoD check with OIA, then errors might be logged from OAACG files.

This problem occurs if the topology entries in the SILConfig.xml file are incorrect. To see these entries, export the SILConfig.xml file from MDS. For default providers, the SILConfig.xml file has the SIL registeration IDs corresponding to the topology names. The IDs in SILConfig.xml and the IDs that SIL registration script returns must be same. For example, the IDs for sodoia topology in SILConfig.xml are:

<IdmId>1</IdmId>
<SodId>7</SodId>
<SDSId>6</SDSId>

Then the IDs returned by the registration script are:

1 oimInstance
6 oimSDSInstance
7 oiaInstance

If these are different, then change the IDs in the SILConfig.xml file and reimport it by using the MDS utility.