Over the years, I have worked with a lot of different customers architecting, developing, deploying, and maintaining their identity provisioning solutions as part of their identity management programs. As both a consultant and working for enterprises, the challenge and expectation is around what the identity provisioning solution can do and how far its reach is.
The Oracle Identity Manager / Governance application has many OOTB connectors for well-known applications (e.g. Active Directory, Exchange, LDAP, etc… ((see full list here) along with generic connector tools and frameworks for applications not currently listed (e.g. DBAT, Generic REST, etc.,) but there are always a number of applications that cannot be fully integrated from an autonomous access and provisioning perspective. Whether this is due to the application being custom, legacy, etc., these applications will always require manual intervention by an administrator to either get users set up, define their level of access or authorization, or all the above.
Let that sink in for a minute. Manual intervention is always going to be around to some degree and is NOT A BAD thing.
Knowing that [insert legacy application name here] is going to require some form of manual intervention to set up users and grant them access, there are usually a couple different flavors of what this looks like.
1. The application has its own authentication and authorization security model and is separate from any other common directory / logins in the organization.
2. The application supports LDAP / Directory for user login but maintains a separate authorization model with defined internal roles.
3. The application supports LDAP / Directory for user login but maintains a separate authorization model with no defined internal roles and has a dynamic authorization model.
When mapping out these flows and application setup processes as mentioned above, usually these are all done through manual request, approval, and setup processes with little / no paper trail of how and when these are done. The response I always get when asking / mapping these out is that the user / manager emails the administrator / owner, they do the work, then the user can login and access the application. There is no central repository or audit trail of this activity leading to significant challenges when trying to answer audit questions around request, approval, access levels, changes of access, etc.
There is a solution to this problem which allows for:
1. Request, approval, and automated assignment of tasks to administrators for manual provisioning and granting of access to users (without having to have another application / process outside Oracle Identity Manager.)
2. Automated change tasks (enable / disable, removal of access, etc.) when the user role changes within the organization.
3. Visibility into user access beyond automated / integrated targets and applications.
Oracle Identity Manager (OIM) has the capability to automate the request process for disconnected applications and systems. This functionality is provided via Disconnected Applications / Manual Fulfillment https://docs.oracle.com/cd/E40329_01/admin.1112/e27149/disconn_resources.htm#OMADM4931″ rel=”noopener” target=”_blank”>(review here.)
This allows you to configure applications, entitlements, requests, etc. like you would a connected application (OOTB connectors) but during the fulfillment of these requests, route the task to administrators to complete. This functionality is hardly advertised or used, but when configured properly (as documented here), can be a huge functionality and visibility boost into your identity provisioning and access management processes.
Like most of the approval, task, and functional routing in OIM, the Disconnected Provisioning process uses SOA composites and integration for assigning and making decisions. By default, the DisconnectedProvisioning composite built into the OIM deployment statically assigns all manual fulfillment tasks to the default OIM administrator (xelsysadm). Anything that is requestable in the OIM catalog, it provides attributes for assigning a Fulfillment User and Fulfillment Role (see below).
Given each application defined in the environment may have different administrators that fulfill the tasks, we need to update the DisconnectedProvisioning SOA composite to use the information defined in the catalog to properly route the fulfillment tasks to the correct administrative user and/or group. With this process in place, using my previous list of example processes when manually requesting / fulfilling access requests, below is what you would have with this in place.
This will move from the manual / no visibility approach of email and helpdesk ticketing to centralizing the access request, approval, and fulfillment processes into OIM.
Making It All Work
Now that we’ve covered the solution and how this can improve the access request, approval, and provisioning process for applications that cannot be fully connected to OIM, let’s go through how you get this working in your environment. The OIM documentation does not cover this in detail (like I said, is often undersold and underutilized) and there are many things you need to do to get this working properly in an enterprise environment. I won’t cover the configuration of the approval components of this process, but will go through how to update SOA to route provisioning tasks to the appropriate administrators defined in the application catalog.
Like I mentioned before, the DisconnectedProvisioning composite in SOA is what defines who will be assigned a Manual Fulfillment task when invoked. To update this to use the catalog metadata information, you need to download the default / OOTB DisconnectedProvisioning composite from the [OIM_HOME]/server/workflows/composites directory.
Once downloaded, you can open the composite in JDeveloper (similar to how you would any approval composite).
If you open ManualProvisioningProcess, you’ll see the default SOA process is limited and does not include much information or logic in the routing of the tasks.
Additionally, when looking at the task assignment rules for the tasks, the default administrator (xelsysadm) is defined as the task owner.
We need to update the composite to use the RequestData service in OIM to add additional information to the task payload that defines the fulfillment information for the task so that you can dynamically assign tasks to the fulfillment users defined in the OIM catalog. To do this, we can use the SOA approval example process defined in the example guide. This will setup the composite for using the request data service. Now since this is not an approval process, but is a provisioning process, there are a few updates to this that need to be made.
The first change that needs to be made is you need to make sure you have a ‘default’ user and role defined. This is in place to make sure in the event the catalog metadata has not been defined, you have an exception loop for task assignment (and won’t fail for the task). I like to use BPEL preferences for these so that it can be updated / dynamic based on the environment and are not hard coded. In the ManualProvisioningProcess source view, add the preferences below for defining the default assignment information (see DEFAULTASSIGNMENTROLE / DEFAULTASSIGNMENTUSER, the others I’ll cover in later posts).
Back in the Design view of the process now, you can add an Assign activity to assign these preferences to global variables in the composite.
In step 188.8.131.52 of the example link provided, for the AssignRequestWSURL activity, it uses the ‘workflowservice’ URL since that will be provided in an Approval request, but since this is a provisioning composite, this will need to be updated to use the provisioning-callback URL settings.
Now, with this configured, you can add the additional Assign and Invoke activities to get the CatalogDetails for the information provided in the payload.
Once you have the catalog details from the task payload, you need to get the fulfillment user and role information details. Since this data can be null in the catalog, you need to make sure you do a check / switch activity to verify and get the details like the below.
Once you have completed getting the details for the fulfillment user and role, you can do data validations to assign the values to be used in the task. In my case, I do a check for null (user or role), and if so, assign the default values from the preferences.
Once this is done, you can assign the values in the task.
With the data assigned, now a new assignment rule needs to be created to use the values for the task routing.
You will then deploy the updated composite version to SOA. You should update the version before deployment to ensure you do not overwrite the default composite that is provided OOTB.
Once this is deployed, and you have a disconnected application and associated roles defined in OIM, a user can login to OIM and request access (in my case here, I have a role defined that includes the disconnected application along with an entitlement.) Once the access has been approved, a member of the fulfillment role for the disconnected application can login and will see the manual fulfillment tasks assigned.
In this case, my sample new request is ffinuser3 and my disable / change in access user is finuser2. The update / change tasks are triggered by a change in status for the user finuser2 so that updates are automatically sent to application administrators.
When looking at the task for ffinnuser3, you can see this is a provision request for the Finance Application.
At this point, the administrator can complete the request in the Finance Application then close this fulfillment task so that it marks the access completed in OIM.
Additionally, since this access request includes an entitlement (FinanceUser), it will send a follow up fulfillment task to the administrator defining the level of access.
In this post my main goal was to go beyond the idea that OIM identity provisioning solution must be fully automated in the sense that all provisioning and deprovisioning operations are hands off. What I’ve shown above is they can be automated from a request, approval, and task perspective and can still be configured to include manual intervention from an application owner / administrator perspective. Once you move to this type of architecture, from an end user they have a single portal for their access information and administrators have a complete view of access requests, approvals, and applications within the environment.
My second goal with this post was to highlight the use of the request data service provider in DisconnectedProvisioning composites. I know this is used a lot in approvals, but I do not see this used in Disconnected Provisioning and is a lot more efficient in terms of retrieving and presenting data within SOA composites.