Enabling SSL Communication Run the following commands from the JAVA_HOMEbin directory:

27-16 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager instrlkv_encoded,concatForm 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 instrlkv_encoded,concatForm data.Application Name,~0 display-field=lkv_decoded save-field=lkv_encoded AttributeReference AttributeReference request-data-set Figure 27–3 shows the SoD Check attributes system attributes as displayed in the request details page after SoD Check is completed: Figure 27–3 The SoDCheckAttributes System Attributes

2. In the IT resource of the connector, create the TopologyName parameter if it does

not already exist. Figure 27–4 shows a sample IT resource in which this parameter has been added: Using Segregation of Duties SoD 27-17 Figure 27–4 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. Figure 27–5 shows the request history for asynchronous SOD check: Figure 27–5 Request History for Asynchronous 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. 27-18 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager 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 Appying the Workflow By Using Approval Policy on page 27-30. 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 27–6 . Note: In Oracle Identity Manager 11g, patches were required on SOA and WebLogic Server to allow the SoD workflow to work. No patch is required with the release of Oracle Identity Manager 11g PS1. 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.