Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle Identity Manager
11g Release 1 (11.1.1)

Part Number E14309-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

24 Understanding Approval Process Development in Oracle SOA Suite

Workflow-based provisioning is a key feature of Oracle Identity Manager that enables you to automate the business processes that manage user access in an organization. Oracle Identity Manager leverages services enabled and managed by Oracle Service-Oriented Architecture (SOA) Suite to provide an interactive environment to request, approve, and manage user access. Oracle SOA Suite provides the back-end services and management capabilities required to implement SOA.

Oracle Identity Manager makes use of the following components of the SOA Suite:

This chapter contains the following sections:

24.1 Integration with Oracle SOA Suite

In Oracle Identity Manager, SOA composites are used as approval processes. Integration of Oracle Identity Manager with Oracle SOA Suite is described in the following sections:

24.1.1 Integration Prerequisites

Before developing SOA composites for Oracle Identity Manager, the following prerequisites are recommended:

24.1.2 Integration Components

The integration of Oracle Identity Manger with Oracle SOA Suite consists of the following components:

  • SOA Suite installation as a part of installing Oracle Identity Manager.

  • One or more SOA composites. You can either extend the default composites shipped with Oracle Identity Manager or develop your own composites.

    See Also:

    Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite for information about developing SOA composites

  • The SOA composite, which consists of:

    • The request payload.

      Oracle Identity Manager provides the SOA composite the details of the request by using XML. This is called the request payload. The SOA composite can use all or part of the payload to determine the next step(s) to take in the approval process. The payload format is fixed.

    • Oracle Identity Manager API calls (optional).

      Oracle Identity Manager provides only the most essential information to the SOA composite to keep the payload small and also to ensure security. If the business process requires additional data, then you can use a Java embedding step to obtain more information about the requester, the beneficiary, or what is being requested. For information on how to invoke Oracle Identity Manager APIs, see Chapter 31, "Using APIs".

    • One or more Human Tasks.

      Human tasks are steps in the overall business process where manual intervention, in the form of approvals, is required. A human task can consist of multiple steps, serial or parallel or a combination of both, where the task is assigned to one or more users or roles or a combination of both. You can define these human tasks and add notification, deadlines, and escalation rules. For information about how to design human tasks, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

      Note:

      In most approval scenarios, the composite contains only one human task. In some instances, additional human tasks may be required if the routing rules cannot be satisfied by using Oracle Business Rules. For example, the composite for resource request type contains multiple human tasks, one per resource. As a best practice, you must try to streamline the approval rules to facilitate reuse of the composites and human tasks.

    • One or more rulesets.

      There are specific business requirements that must be met when fulfilling requests. SOA composites leverage Oracle Business Rules to satisfy these requirements. A collection of rules developed by using Oracle Business Rules is called a ruleset. A composite can have one or more rulesets. Human tasks can also leverage these rules to determine the participants and the task routing. For information about how to design human tasks, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

  • A certified version of JDeveloper, for example, JDeveloper 11.1.1.3.

  • The SOA Design Time, also known as the SOA Composite Editor Extension for JDeveloper.

24.2 Predefined SOA Composites

Table 24-1 lists the predefined SOA composites in Oracle Identity Manager that can be used as approval processes.

Table 24-1 Predefined Workflow Composites

Workflow Composite Description

DefaultRequestApproval

This is the default request-level approval. By default, the request-level approval goes to the System Administrator, xelsysadm, for request-level approval.

DefaultOperationalApproval

This is the default operation-level approval. By default, the approval task is assigned to the System Administrator, xelsysadm, for operation-level approval.

BeneficiaryManagerApproval

This acquires approval from the beneficiary's manager. This can be associated with the following:

  • The request types that have a beneficiary. Examples of such request types are Provision Resource and Assign Roles.

  • All user models except Create User and Self-Register User.

This composite must be associated at the operational level of approval because a request can have multiple beneficiaries at the request level.

DefaultRoleApproval

This SOA composite creates a single approval task that is assigned to the SYSTEM ADMINISTRATORS role for approval.

RequesterManagerApproval

This SOA composite creates a single approval task that is assigned to the requester's manager for approval.

Note: This cannot be associated with unauthenticated request types, such as Self Register User.

ResourceAdministratorApproval

This SOA composite creates a single approval task that is assigned to the SYSTEM ADMINISTRATORS role for approval. This must be associated with the request types that are related to resources. This composite is used at the operational level of approval.

ResourceAuthorizerApproval

This SOA composite creates a single approval task that is assigned to resource authorizers (with highest priority) for approval. This must be associated with the request types that are related to resources. This composite is used at the operational level of approval.

DefaultSODApproval

This SOA composite creates an approval task that is assigned to the system administrator, starts SoD check, and after the SoD result is available, it creates another approval task assigned to the SOD Administrators role. This must be associated with request types to provision or modify resources at the operational level if SoD check is required.


Note:

Human tasks in these default composites are configured to send notifications to the assignee of the human task.

For configuring Oracle SOA server to send e-mail notifications, see "Configuring Oracle User Messaging Service" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

In addition to the SOA composites listed in Table 24-1, the AutoApproval composite is available in SOA. But Oracle recommends that users must select the Auto Approval option rather than using the AutoApproval composite to avoid a round trip from Oracle Identity Manager to SOA. This is because in an approval policy, if a user selects the Auto Approval option, then for a request that matches this approval policy, it is auto approved in Oracle Identity Manager. The approval does not go to SOA and come back. However, in an approval policy, if a user selects the AutoApproval as the approval process, then for a request that matches this approval policy, the AutoApproval composite is initiated in SOA and immediately a response 'Approved' is sent back to Oracle Identity Manager.

24.3 Developing an Approval Process for Oracle Identity Manager

To develop an approval process for Oracle Identity Manager:

Note:

As a part of developing an approval process for Oracle Identity Manager, you must create request datasets, upload the request datasets to MDS, create or use request templates, and create approval policies. For details, see Chapter 23, "Configuring Requests".

  1. Create a JDeveloper workspace by using the new_project.xml utility. This utility is in the OIM_HOME/workflows/new-workflow/ directory. See "Creating a New SOA Composite" for details.

  2. Open the JDeveloper workspace and modify the BPEL process and the human task as required.

  3. Deploy the composite in any one of the following ways:

24.4 Monitoring Oracle Identity Manager SOA Composites

Oracle Identity Manager SOA composites are managed and monitored by using Oracle Enterprise Manager Fusion Middleware Control Console. For more information about managing and monitoring deployed SOA composites, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

24.5 Enabling Oracle Identity Manager to Connect to SOA

Oracle Identity Manager connects to SOA as SOA administrator, for which the username is "weblogic" by default. During the Oracle WebLogic Server domain creation, if the username provided is other than this, then Oracle Identity Manager is not able to connect to SOA as SOA administrator. To enable Oracle Identity Manager to work with any Oracle WebLogic Server administrator user, and thereby, connect to SOA without any problem, perform the following postinstallation steps:

  1. Login to Enterprise Manager by using the following URL:

    http://ADMINSERVER_HOST:ADMINSERVER_PORT/em

  2. Right click Identity and Access/oim(11.1.1.3.0), and select System Mbean Browser.

  3. Expand oracle.iam under application-defined Mbeans, and select Server: OIM_SERVER_NAME, Application: oim, XML config, config, XMLConfig.SOAConfig, and then select the SOAConfig Mbean.

  4. View the username attribute. By default, the value of this attribute is weblogic. Change this to the correct Oracle WebLogic Server administrator username.

  5. Click Apply.

  6. Navigate to the OIM_ORACLE_HOME/common/bin/ directory in the Oracle Identity Manager deployment.

  7. Start the WebLogic Scripting Tool (WLST) by running the following command:

    ./wlst.sh
    
  8. At the prompt, enter connect(). When prompted, enter the Oracle WebLogic Server administrator username, password, and administrative server connection string.

  9. To delete the default SOA administrator username and password credential from CSF, run the following command:

    deleteCred(map="oim", key="SOAAdminPassword");
    
  10. To create the new credential that Oracle Identity Manager uses to connect to SOA as SOA administrator, run the following command:

    createCred(map="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:

    listCred(map="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.