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