OIM 11g OID (LDAP) Groups Request-Based Provisioning with custom approval – Part II

Introduction

This is Part Two of the article describing a potential implementation of Request Based LDAP Group Membership provisioning. Part One can be accessed here.

Continuing with the implementation after disabling the default approval policies at the Request and Operation Levels, the next step is to configure OIM to enable the modification of a provisioned resource via a request. The datasets associated to the Create and Modify operations of the resource in questions (OID User in this case) have to be imported into MDS. The connector’s installer at the present time doesn’t do the import of the metadata files to enable request based operations for the connector; this has to be done after installation by running the corresponding MDS utilities available in OIM.

Importing Connector’s Data Sets into MDS

The files containing the definition of the data collected by the Provisioning operations are called data sets. For OID User, there are two DataSet XML files:

• ModifyResourceOID User.xml
• ProvisionResourceOID User.xml

The one that we will need is the ModifyResourceOID User.xml. Here is the data set below:

From this data set this is what we will need for our implementation:

‘OID User Groups’ will be used as the attribute name to construct the RequestBeneficiaryEntityAttribute as shown in the code snippet below:

If you see any required attributes in the data set, you will have to create a value for the RequestBeneficiaryEntityAttribute for that attribute reference in the data set. The OID Server is one of those attributes. Also for the insertion of Child table records here is the specific code fragment for that:

Notice that we have to use the actual Database Table field name which can be retrieved from the Form Definition. See below:

Uploading DataSets into MDS

In this section I describe the process to upload DataSet XML files into MDS for OIM to use in Request Based Provisioning. As most of you know Data Sets determine the Fields collected during the provisioning process and certain attributes of those fields that make them required, pre-populated or only visible to the approvers. We won’t get into the details of the structure of the data sets involved here but at least we will cover a simple procedure for importing them into MDS. MDS is the acronym for Meta Data Store. Many applications part of the Fusion Middleware family rely on MDS to store configuration or Application Metadata.

This implementation works with OID’s data sets so this is the procedure to import them into MDS:

• Create a directory inside // called DataSet/file (i.e in my case the directory is /opt/fmw11g/Oracle_IDM1/DataSet/file where my Middleware Home is /opt/fmw11g and my OIM installation resides under Oracle_IDM1 directory).
• Copy all the datasets from the connector’s binaries home into the directory you just created in the previous step.
• Switch to the bin directory inside the server directory under you OIM home directory (i.e. in my case /opt/fmw11g/Oracle_IDM1/server/bin).
• Modify the file weblogic.properties inside the directory mentioned above. Here is mine:

Wls_servername is the name of the managed server as you defined it in the WebLogic Domain.
Application_name is always ‘oim’.
Metadata_from_loc is the path to the directory created in the first step. Specify this path omitting the last directory in the path (‘file’) as shown in the figure. So if you have a directory /opt/fmw11g/Oracle_IDM1/DataSet/file then the path should be specified as /opt/fmw11g/Oracle_IDM1/DataSet.

• Set the OIM_ORACLE_HOME to your OIM installation Home (i.e. in my case this is what I did export OIM_ORACLE_HOME=/opt/fmw11g/Oracle_IDM1).Run the weblogicImportMetadata.bat|sh script. The script will ask the following:
• User name: weblogic (Do not use xelsysadm)
• Password:
• Server URL: t3://myOIMHost:14000 # Provide the URL to your oim managed server and oim's port.

• You should get an output similar to the one described below:

  

  
  

  Run the script PurgeCache.bat|sh. Before running the script you need to set WL_HOME and JAVA_HOME environment variables with your location of WebLogic Server installation directory and path to a valid Java JDK/JRE directory (i.e. WL_HOME=/opt/fmw11g/wlserver_10.3 and JAVA_HOME=/opt/fmw11g/jdk160_24 coming with my FMW installation). The output should be similar to the following:

In this case the user has to be xelsysadm instead of weblogic.

Configuring the Human Task (Custom Approval Process SOA Composite)

Now it is time to look in detail at the SOA Composite that will serve as an approval process for our entitlements (LDAP Groups). Look at the following set of pictures:

From the Composite.xml design view in JDeveloper, right click on the Green Human Task icon and select Edit.

Select the Participant block and the click the Edit button at the top of the screen. This brings the screen shown below:

Notice the Value Column of the participant selection table. It is a User whose Login ID is retrieved from the payload in this case: /task:task/task:ownerUser. This is populated in the early stages of the composite right after the corresponding approver is retrieved from the Entitlements_Staging Database table for the requested Entitlement identified by the field EntitlementID. This information is retrieved by the Database Adapter Web Service configured to execute a query against the Entitlements_Staging table part of the schema defined in our solution. For information on how to configure the Database Adapter task in a BPEL process, see the documentation for Fusion Middleware – SOA Suite.

Summary

In summary this post describes a potential approach to implement Request Based OID User Group Membership provisioning using a custom approval process.

The concepts shown in this post include:

• A description of OIM API’s to construct and submit requests to modify provisioned resource.
• A demonstration of the process of configuring Custom Approval Processes via Request Templates.
• A description of the OIM configuration required to disable the default Request and Operation level approvals.
• The steps necessary to customize the SOA composite to extract required Entitlement and Associated Approver information and how to set up the Participants of the Human Task used to Approve/Reject requests.
• The steps to import metadata required to enable request based provisioning for OID Resource Objects (Users and Groups).

For further details about configuration of OIM for Provisioning Processes, Process Forms, Access Policies and any details mentioned but not covered in detail in this post please access OIM Fusion Middleware Documentation from the Fusion Middleware 11g documentation.