Integration with Oracle SOA Suite

24-6 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager createCredmap=oim, key=SOAAdminPassword, user=xelsysadm, password=ADMINISTRATOR_PASSWORD; Replace ADMINISTRATOR_PASSWORD with the actual password. 11. Confirm that the correct value has been seeded by running the following command: listCredmap=oim, key=SOAAdminPassword; 12. Exit WLST shell by running the following command: exit 13. Login to Oracle Identity Manager Administrative and User Console by using the administrator login credentials. 14. Create a new user with the same login ID as the Oracle WebLogic Server administrator username. 15. Search for the Administrators role. Open the role details and click the Members tab. 16. Remove all the existing members of the role. 17. Add the newly created user as member of this role. 18. Confirm that this role has only one member. This member must be the user created in step 14. 19. Restart Oracle Identity Manager managed server. 25 Developing SOA Composites 25-1 25 Developing SOA Composites The primary goal of any provisioning system is to manage requests submitted by users and provision resources to users. Request completion involves execution of associated approval processes. These approval processes are deployed as Service Oriented Architecture SOA composites running on the SOA Server. Request service is responsible for execution and management of such approval processes. Figure 23–1, Request Service and SOA Integration shows the integration of the request service and SOA. The interaction between Oracle Identity Manager and SOA Server is explained in the following steps: 1. The user creates a request by using the Oracle Identity Manager Self Service. The request can be of any one of all the request types supported by Oracle Identity Manager. 2. Request service evaluates the approval policy, and the SOA composite to be instantiated is selected. 3. Request service contacts SOA Server to instantiate the selected SOA composite. Instantiates selected composite instance on SOA server. 4. SOA composite run starts and human approval task is assigned for approval. 5. The approver logs in to the Task List in the Oracle Identity Manager Self Service console, and approves the request. 6. After the approval, the composite instance run is completed, which is notified to the request service. 7. Request service moves the request to the next stage. This chapter discusses the following topics: ■ Creating New SOA Composites ■ Modifying Existing SOA Composites Note: The composites must be registered with Oracle Identity Manager in order for them to be kicked off when the request is submitted. For information about registering workflows with Oracle Identity Manager, see Registering a SOA Composite with Oracle Identity Manager on page 25-4. 25-2 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager

25.1 Creating New SOA Composites

To create a new SOA composite that can be used as an approval process, you must perform the following steps: 1. Creating a New SOA Composite 2. Deploying a SOA Composite in Oracle SOA Server 3. Prerequisites for Communication to Oracle Identity Manager Through SSL Mode 4. Registering a SOA Composite with Oracle Identity Manager

25.1.1 Creating a New SOA Composite

To use a SOA composite as an approval process, it must adhere to certain standards. These standards ensure that the request service is able to instantiate and manage such composites correctly. These standards are: ■ The following attributes are mandatory for BPEL process: – RequestID of type String – RequestModel of type String – RequestTarget of type String – URL of type String – RequesterDetails of XML Element – BeneficiaryDetails of XML Element – ObjectDetails of XML Element – OtherDetails of XML Element The RequestID, RequestModel, RequestTarget, and URL attributes are always set with valid values for all types of requests. RequesterDetails is an XML element. This element is filled up with valid values for all requests that requires authentication. Requester details is empty for the requests of type Self-Register User because the requester is anonymous user. BeneficiaryDetails is an XML element. This element is filled up with valid values for all requests that have a beneficiary, for example, Provision Resource and Assign Roles. This is filled up only if the request is associated with single beneficiary. If the request is associated with multiple beneficiaries, then BeneficiaryDetails is empty. BeneficiaryDetails element always has valid value for simple requests and child requests that have a beneficiary. Therefore, it is recommended to use this XML element in SOA composites that are used as approval processes at the operational level of approval. This is because at the operational level of approval, the request is associated with only one beneficiary. ObjectDetails is an XML element. This element is filled up with valid values for all requests that are associated with the Resource entity. This is filled up only if the request is associated with single resource. If the request is associated with multiple resources, then ObjectDetails is empty. The ObjectDetails element always has valid value for simple and child requests that are associated with resource. Therefore, it is recommended to use this XML element in SOA composites that are used as approval processes at the operational level of approval. This is because at the operational level of approval, the request is associated with only one resource.