Introduction
In recent days, I was assigned the task to implement a use case that I am sure many customers of Oracle have in mind but are not sure how to implement in OIM 11g. I even saw some thread inquiring about this very topic with no answer. Well, after some time I was able to put together an implementation of a Custom Approval process and a Custom UI based on ADF to request entitlements for users which in turn will be converted to Group memberships in OID (this also applies to any standard LDAP connector supported by OIM since the architecture is very similar for all of them). This article will be divided in 2 parts.
To give the audience a little overview this diagram shows the architecture of the solution:
As shown in the figure above, the use case is implemented by taking advantage of a very powerful feature of OIM 11g, which is the integration with SOA to execute custom composites as approval processes. Inside the custom composite an invocation to a Web Service that implements the logic to insert records on the Child Table associated with the provisioning process instance of OID User Resource Object that in turn is associated with the Beneficiary of the original request. When an administrator provisions entitlements to a given person the following sequence of steps takes place:
There are several important things to keep in mind here:
Main Article
Now, let’s start with the procedure to make this happen. In order to implement this functionality we are going to need the following components in our solution:
This component is the one that does the heavy lifting when it comes to creating and submitting Modify Provisioned Resource Requests to OIM.
The figure below is the constructor of the Process Task. The parameters to the constructor allow the class to connect to the database hosting the Staging Table with the entitlements per user:
The figure shown next shows the method that obtains the entitlements for a given user and traverses the result set to submit requests for entitlements requiring approval or insert the records in OID User RO’s child table which will trigger the addition of the user into the corresponding group on the target system.
Here is the method that processes the entitlements returned by the query:
Notice the method buildBeneficiaryData presented below. This is a very important method since it actually builds the main structure of the request before submitting it.
This is the method that does direct provisioning of LDAP Groups:
The RESOURCE constant has the value of “OID User”.The RESOURCE_ATTR_NAME constant has the value of “Objects.Name”. This is to work with OID User Resource Object, if you need to work with a different LDAP Server, replace the value of this constant with the name of your LDAP Server Associated Resource Object.
For retrieving user attributes, we provide the following method:
Configure this task to be a dependant of the Create User Task of the OID User Provisioning process. That will ensure that the task only executes when the OID User has been successfully provisioned. For details on how to accomplish this, please refer to the OIM documentation part of the Fusion Middleware 11g documentation set.
The requirement for this scenario is that some entitlements require approval from an Approver or a Sponsor depending on the type of entitlement being requested. Internal users request only Internal type entitlements and External users can only select External entitlements. This is enforced by the User Interface by displaying a list of selectable entitlements according to the type of user to be created in OIM. The most important elements to notice are:
The invocation task labeled as callGetEntApprover. This Task gets the Login ID of the BeneficiaryDetails and the Entitlement ID taken from the ObjectDetails parts of the inputVariable’s payload, which contains all the request data.
The invocation task labeled as call_addUserToLDAPGroup included in the block that is executed when the task gets approved. The Web Service takes two parameters:the login ID of the beneficiary and the entitlement ID of the requested entitlement. Both pieces of data come from the request data available in the inputVariable’s payload.
Out of the box, OIM has Request and Operation level approvals configured for standard requests. Both of these send an approval request to XELSYSADM and OIMINTERNAL user which are both part of the SYSTEM ADMINISTRATORS group. If this is not the desired effect, here is how to disable these approvals:
Create an Approval Policy for Request Level, the configuration from my implementation is presented below:
Now for the Operation Level approval here is the Approval Policy shown in the figure below:
Notice the value in the Scope of the policy: OID User. This is required for operation level Approval Policies. You have to select the Resource Object for which the Approval Process is defined. In my case it is the OID User but in other cases it could be iPlanet User, AD User, etc. The easiest way to do it is by Composite Name which is what I did for these two Approval Policies.