24 Configuring SoD Validation

24.2.1.1.1 Modifying the Approval Workflow for SoD

To modify the approval workflow for SoD validation:

1. Instead of object forms in earlier releases of Oracle Identity Manager, the data to be entered while creating a request in 11g Release 1 (11.1.1) is entered in request datasets. If the request datasets are not already present for the target system resource to be provisioned, then create new parent and child datasets and import them to MDS by using the MDS Import Utility.

   Note:

   • No SoD Check fields must be added in the request dataset. These fields are part of common dataset and is available by default irrespective of the connector being used. The SoD fields in the common dataset are

     <!-- Common SoD check attributes used for Provision Resource -->
     <AttributeReference name="SoDCheckStatus" attr-ref="SoDCheckStatus" length="50" type="String" widget="text" read-only="true" available-in-bulk="false" system-type="true"/>
     <AttributeReference name="SoDCheckTrackingID" attr-ref="SoDCheckTrackingID" length="50" type="String" widget="text" read-only="true" available-in-bulk="false" system-type="true"/>
     <AttributeReference name="SoDCheckResult" attr-ref="SoDCheckResult" length="4000" type="String" widget="text" read-only="true" available-in-bulk="false" system-type="true"/>
     <AttributeReference name="SoDCheckTimestamp" attr-ref="SoDCheckTimestamp" length="50" type="Date" widget="text" read-only="true" available-in-bulk="false" system-type="true"/>
     <AttributeReference name="SoDCheckEntitlementViolation" attr-ref="SoDCheckEntitlementViolation" length="4000" type="String" widget="text" read-only="true" available-in-bulk="false" system-type="true"/>
     

     Here, the <attr-ref> tag values represent mapping to process form fields. Therefore, any connector enabled for SoD must have these specific form field labels in the parent process form. For example, SoDCheckStatus attribute value is mapped to parent process form field with label as SoDCheckStatus.

   • For detailed information about request datasets, see "Step 1: Creating a Request Dataset for the Resources".

   • For information about MDS Import/Export Utility, see Chapter 30, "MDS Utilities and User Modifiable Metadata Files".

   • Object forms in earlier releases of Oracle Identity Manager have been replaced by request datasets in 11g Release 1 (11.1.1). Therefore, although the object forms may be present in the connector, they are not used.

   The following is a sample request dataset for the eBusiness Suite User TCA Foundation resource. Create an appropriate request dataset for the resource being used.

   <request-data-set xmlns="http://www.oracle.com/schema/oim/request"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.oracle.com/schema/oim/request"
          name="eBusiness Suite User TCA Foundation"    entity="eBusiness Suite User TCA Foundation" operation="PROVISION">
           
           <!-- Parent form having fields -->
    
           <AttributeReference name="Effective Date From" attr-ref="Effective Date From" type="Date" length="50" widget="date" required="true" available-in-bulk="true"/>
           <AttributeReference name="SSO GUID" attr-ref="SSO GUID" type="String" length="256" widget="text" required="false" available-in-bulk="true"/>
           <AttributeReference name="Last Name" attr-ref="Last Name" type="String" length="150" widget="text" required="false" available-in-bulk="true"/>
           <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"/> 
           <AttributeReference name="Password Expiration Interval" attr-ref="Password Expiration Interval" type="Long" length="50" widget="text" required="false" available-in-bulk="true"/>
           <AttributeReference name="Fax" attr-ref="Fax" type="String" length="80" widget="text" required="false" available-in-bulk="true"/>
           <AttributeReference name="Password" attr-ref="Password" type="String" length="30" widget="text" masked="true" required="true" available-in-bulk="true"/>
           <AttributeReference name="Effective Date To" attr-ref="Effective Date To" type="Date" widget="date" length="50" required="false" available-in-bulk="true"/>
           <AttributeReference name="Description" attr-ref="Description" type="String" length="240" widget="text" required="false" available-in-bulk="true"/>
           <AttributeReference name="Password Expiration Type" attr-ref="Password Expiration Type" type="String" length="30" widget="lookup" required="false" available-in-bulk="true" lookup-code="Lookup.EBS.PasswordExpirationType"/>
           <AttributeReference name="SSO User ID" attr-ref="SSO User ID" type="String" length="256" widget="text" required="false" available-in-bulk="true"/>
           <AttributeReference name="User Name" attr-ref="User Name" type="String" length="100" widget="text" required="true" available-in-bulk="true"/>
           <AttributeReference name="First Name" attr-ref="First Name" type="String" length="150" widget="text" required="false" available-in-bulk="true"/>
                   <AttributeReference name="Party ID" attr-ref="Party ID" type="Long" widget="text" length="50" required="false" available-in-bulk="true"/>
           <AttributeReference name="User ID" attr-ref="User ID" type="Long" widget="text" length="50" required="false" available-in-bulk="true"/>
           <AttributeReference name="Email" attr-ref="Email" type="String" length="240" widget="text" required="false" available-in-bulk="true"/>
    
           
               <!--  Child form EBS -->
           <AttributeReference name="UD_EBST_RSP" attr-ref="UD_EBST_RSP" type="String" length="20" widget="text" available-in-bulk="true">
           <AttributeReference name="Effective Start Date" attr-ref="Effective Start Date" type="Date" length="50" widget="date" required="false" available-in-bulk="true"/>
           <AttributeReference name="Effective End Date" attr-ref="Effective End Date" type="Date" length="50" widget="date" required="false" available-in-bulk="true"/>
           <AttributeReference name="Application Name" attr-ref="Application Name" type="String" length="256" widget="lookup" required="false" available-in-bulk="true" lookup-code="Lookup.EBS.Application"/>
           <AttributeReference name="Responsibility Name" attr-ref="Responsibility Name" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="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> 
    
           </AttributeReference>
    
           <AttributeReference name="UD_EBST_RLS" attr-ref="UD_EBST_RLS" type="String" length="20" widget="text" available-in-bulk="true">
           <AttributeReference name="Start Date" attr-ref="Start Date" type="Date" widget="date" length="50"  required="false" available-in-bulk="true"/>
           <AttributeReference name="Expiration Date" attr-ref="Expiration Date" type="Date" widget="date" length="50" required="false" available-in-bulk="true"/>
     
           <AttributeReference name="Application Name" attr-ref="Application Name" type="String" length="256" widget="lookup" required="false" available-in-bulk="true" lookup-code="Lookup.EBS.Application"/>
           <AttributeReference name="Role Name" attr-ref="Role Name" type="String" length="256" widget="lookup-query" available-in-bulk="true" required="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.UMX.Roles' and instr(lkv_encoded,concat('$Form data.Application Name','~'))>0" display-field="lkv_decoded" save-field="lkv_encoded"/> 
             </AttributeReference> 
        </AttributeReference>
   </request-data-set>
   

   Figure 24-2 shows the SoD Check attributes system attributes as displayed in the request details page after SoD Check is completed:

   Figure 24-2 The SoDCheckAttributes System Attributes

   
   Description of "Figure 24-2 The SoDCheckAttributes System Attributes"
   
   

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

   Figure 24-3 The TopologyName Parameter

   
   Description of "Figure 24-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 24-4 shows the request history for asynchronous SOD check:

   Figure 24-4 Request History for Asynchronous SoD Check

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

3. 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. For using the default workflow, see 0, "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 asynchronous SoDCheck Web service to start SoD check. To complete and callback the SoDCheck Web service, you must run the 'Get SOD Check Results Approval scheduled job. The workflow with SoDCheck Web service call is shown in Figure 24-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.

   Figure 24-5 Workflow with SoDCheck Web Service Call

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

   After this, a switch case with approval tasks are assigned to the SoD 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 24-6:

   Figure 24-6 Switch Case With Approval Tasks

   
   Description of "Figure 24-6 Switch Case With Approval Tasks"
   
   

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

   Figure 24-7 Assignment of the Approval Task

   
   Description of "Figure 24-7 Assignment of the Approval Task"
   
   

   Approval workflow has migrated to BPEL in Oracle Identity Manager 11g Release 1 (11.1.1), 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 24-8 shows the default workflow modified to perform SoD Check after human approval:

      Figure 24-8 Modified Workflow To Perform SoD Check

      
      Description of "Figure 24-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 24-9:

      Note:

      BPEL connects to all external entities through a partner link.

      Figure 24-9 SoD Check Partner Link

      
      Description of "Figure 24-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 24-1:

        Table 24-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 24-10 shows the final assign activity:

        Figure 24-10 Final Assign Activity

        
        Description of "Figure 24-10 Final Assign Activity"
        
        

      • INVOKE: The details for this activity are:

        Interaction Type: Partnerlink

        Partnerlink: SODCheckService

        Operation: Initiate

        Input Variable: SODInvoke_initiate_InputVariable

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

        Figure 24-11 The Invoke Dialog Box

        
        Description of "Figure 24-11 The Invoke Dialog Box"
        
        

      • RECEIVE: The details for this activity are:

        Interaction Type: Partnerlink

        Partnerlink: SODCheckService

        Operation: Result

        Variable: SODResultReceive_result_InputVariable

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

        Figure 24-12 The Receive Dialog Box

        
        Description of "Figure 24-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 24-13:

        Figure 24-13 Switch Case

        
        Description of "Figure 24-13 Switch Case"
        
        

      • 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 SOD administrators role. DefaultSODApproval always assigns approval task to the SoD 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 24-14:

      Figure 24-14 Configuring WS Policies for Request

      
      Description of "Figure 24-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 24-15, and then click OK.

      Figure 24-15 Select Client Security Policies

      
      Description of "Figure 24-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 24-16, and then click OK.

      Figure 24-16 Select Server Security Policies

      
      Description of "Figure 24-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:

      Chapter 21, "Developing SOA Composites" for general procedure for creating a new workflow and registering it with Oracle Identity Manager

   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.

24.2.1.1.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.

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 screenshot shows this Holder task:

   
   

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

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

   
   

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

   
   

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

   The following screenshot shows the SODChecker task:

   
   

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.
   SODCheckNotInitiated	C	The SoD validation process has not been initiated because SoD has not been enabled in Oracle Identity Manager.

   
   

   The following screenshot shows these response codes:

   
   

24.2.1.2.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>

24.2.1.2.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" for information.

24.3.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.

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 CUA or 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 24-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.

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

24.3.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.