Infosys Limited (NYSE:INFY) is a global leader in technology, consulting and services and an Oracle (Diamond) Partner that has graciously agreed to present on best practices garnered from experience working on large enterprise Identity Management (IDM) deployments in a four part series hosted here in the Identity Management Blog. In this part-2 of the four part series Infosys shares its experience with disconnected application framework for implementing manual provisioning for a large set of applications in Oracle Identity Manager 11g R2 PS1.
In our first blog, we discussed the need to build an abstraction layer to allow for consolidation of identity, account and access information from Oracle Identity Manager (OIM) and other enterprise sources. In the second edition, we will continue exploring further on theme of how organizations can earn an accelerated ROI from the new IDM infrastructure by adopting “Disconnected Application framework”.
Introduction to Disconnected Application Framework in OIM
The first step of introducing an enterprise IDM solution is to build an identity warehouse by reconciling identity sources and key target systems. This is followed by use case deployments like password management, automated provisioning/de-provisioning to platforms, access certifications, etc. These features allow the organizations to make big strides and provide much needed relief to the administration side of identity management operations and compliance teams.
For the lines of business though, automating the access provisioning/de-provisioning of applications holds the key to achieve the desired efficiency of identity management as well as reduction in costs associated with manual provisioning. However, it takes time and effort to fully automate provisioning/de-provisioning to the hundreds of applications in the enterprise ecosystem. Although this might sound a little discouraging for enterprise leaders and architects, there is a middle way to handle the above scenario.
In order to achieve the desired ROI of implementing an integrated IDM solution, Infosys recommends a hybrid model for implementing application provisioning. In our approach, we ask architects and business owners to participate in an application profiling exercise that involves rating of applications across a range of criteria. The questionnaire includes parameters around application criticality, compliance needs, required speed and complexity of provisioning & de-provisioning, complexity of approval workflow, availability of out-of-box integrations etc. The profiling exercise provides the team with a list of potential automation candidates as well as a list of applications that can be onboarded for manual provisioning. Nonetheless, as an IDM integrator, we maintain the focus on providing the key benefits of the IDM solution to the organization for both automated and manual application provisioning.
Key Benefits of Application Integration with an IDM Solution:
- Speedy/efficient, centralized and secure provisioning processes
- Scalable provisioning model
- Compliance adherent application model
In this blog we will focus on the ‘Disconnected Application Framework’ in OIM which can be leveraged by enterprises to easily integrate large number of applications for manual provisioning. We will also present the high level process that should be followed while using the framework. This process was evolved from our recent experience of integrating hundreds of applications in OIM 11g R2 PS1 for manual provisioning at a large enterprise.
In the earlier versions of OIM, one had to explicitly create a custom resource object and associated connector artifacts and use manual tasks for each of the application to assign tasks to application administrators for manual provisioning. It was effort intensive and had its own limitations. OIM 11g R2 offers the concept of disconnected resource/application for easier integration of applications for manual provisioning. This feature leverages existing OIM provisioning components like resource object, provisioning process, provisioning form etc. while providing a seamless integration with SOA engine for manual provisioning workflow. The ‘disconnected application framework’ in OIM provides a browser based creation, configuration and administration of application instances to integrate applications that do not have connectors for automated provisioning.
Here is a list of advantages of the ‘Disconnected Application Framework’:
- Easy creation, configuration and administration of application instances
- Browser based application form UI customizations
- Automated backend creation of underlying connector objects
How to create a single disconnected application?
In one of our recent large scale IDM implementations we had to integrate 150+ applications for manual provisioning with OIM 11g R2 PS1 in a short span of time. During the integration, we noticed that the process of creating and configuring one disconnected application is simple.
High Level process of creating a disconnected application instance:
Steps on OIM Admin Interface
- Create a Sandbox
- Create an application instance by selecting the “Disconnected” checkbox in the application instance form
- Create the application instance form
- Export the Sandbox as zip file for backup
- Publish the Sandbox
Steps on OIM End User Interface
- Create a Sandbox
- Search and select the application in the catalog
- Perform any UI level customizations required for the application instance form
A Sandbox in OIM provides a mechanism to isolate the customizations by analysts at runtime enabling the analysts to work on the customizations without affecting the experience of other analysts until the Sandbox is published.
As shown in Figure 1. Application Instance Artifacts below, at the surface we are dealing only with Sandbox to create disconnected application instances. In the background OIM automatically creates the relevant connector objects that are needed for the application. These connector objects are directly created in database even without publishing the Sandbox and are not stored in the Sandbox zip file that is exported.
Figure 1. Application Instance Artifacts
How does the sandbox feature work in OIM 11g?
Sandbox feature in OIM 11g works similar to a typical versioning system but with a distinction. Every time a Sandbox is created a separate copy of the underlying artifact(s) is created from the mainline and all customizations performed within the Sandbox are contained within the ‘copy’ artifact(s) created for that Sandbox.
The distinction of Sandbox from a versioning system is that whenever a Sandbox is published, the artifact(s) in the mainline are overwritten with the ‘copy’ artifacts from the Sandbox instead of merging the changes. This behavior of the Sandbox poses a challenge if you want to create application instances in parallel.
A typical thought process to accelerate creation of disconnect application instances can be to distribute applications among a team of analysts creating applications in parallel in the development environment of OIM 11g.
However in this scenario, where analysts create their own Sandboxes to work in parallel, when an analyst publishes the Sandbox they have created it will overwrite all customizations published by previous analysts. This results in errors related to missing view objects in UI while requesting the applications in Catalog.
How to scale the framework for integrating large number applications?
To resolve the issues that can arise from concurrent application instance creations as explained above, we have come up with best practices that can be followed:
- In single development environment, create and publish applications in sequence. The issue with overwriting of files will not allow you to gain any efficiency of scales. Slow and steady wins the race here.
- If you have the luxury of multiple development environments, then create applications in parallel on these separate environments and combine them while migrating to higher environments. Utmost care is needed when combining the applications.
- Instead of create application in one sandbox, it is a good practice to create separate sandboxes for each of the applications
- Once a sandbox is published, it cannot be exported. As a best practice export and save the sandbox with a naming convention capturing the application name, time stamp and version before publishing it
Migrating disconnected applications between environments
Once disconnected applications are created and tested in a lower environment, the next step is to migrate these applications to a higher environment. Migrating an application from one environment to another involves exporting and importing of Sandbox and connector objects.
Note: While migrating the application instances when you import the Sandbox from one environment
to another environment,
the files in the Sandbox (BizEditorBundle.xlf and CatalogAM.xml)
from source environment
will be overwritten on the files in the target/destination environment.
It is necessary to merge the changes from source environment Sandbox files with the destination environment Sandbox files.
Process for migration of applications from source to destination environment:
Step 1: Export application artifacts from source environment
We recommend that the steps be repeated for each of the application to be migrated.
- Using Deployment Manager export Application instance corresponding to an application along with dependencies and save as a file (e.g. App1_instance_source.xml)
E.g. of dependencies: Resource, Process Form, Process, IT Resource Definition, IT Resource, Lookup
- Using Deployment Manager export Request Dataset corresponding to the application and save it to a file (e.g. App1_Req_Dataset_source.xml)
- Get the Sandbox zip file that was exported before publishing in the source environment (e.g. App1_Sandbox_source.zip)
Step 2: Extracting and preparing destination artifacts
The following steps will be completed in destination environment in preparation for merging the sandbox artifact changes from lower environment.
- Backup the complete Metadata Services (MDS)
- Get latest version of BizEditorBundle.xlf and CatalogAM.xml files form destination
- Method 1: Create a dummy Sandbox and create a dummy application
- Method 2: Create a dummy Sandbox and edit an existing application instance with a very minor change
The above 2 methods will get you the latest version of BizEditorBundle.xlf and CatalogAM.xml files from destination into your dummy sandbox.
- Export the Sandbox (e.g. Destination_DummyApp_Sandbox.zip)
- Publish the Sandbox created above
- Copy and extract the Sandbox zip file (Destination_DummyApp_Sandbox.zip) to a folder on a machine from which you can access OIM admin interface of the destination environment
Let us call it Master_Sandbox_Destination folder.
Step 3: Importing Applications in the destination environment
Repeat the below steps to migrate each application exported from source
environment in Step 1
i. Using Deployment Manager import the application instance xml file (App1_instance_source.xml) followed by import of the request dataset xml file (App1_Req_Dataset_source.xml) exported from the source environment in Step 1
ii. Extract the application Sandbox zip from the source environment of Step 1 (App1_Sandbox_source.zip)
a. Open xliffBundles\oracle\iam\ui\runtime\BizEditorBundle.xlf and copy the elements corresponding to the application being migrated and merge them with the BizEditorBundle.xml in the extracted Sandbox zip file from destination environment (i.e Master_Sandbox_Destination folder). You can look for the ‘trans-unit’ elements with the application instance form name of the application that is being migrated. The first element always corresponds to ITResource. Below is an example
b. Open persdef\oracle\iam\ui\catalog\model\am\mdssys\cust\site\site\CatalogAM.xml file and copy the elements corresponding to the application being migrated and merge them with the CatalogAM.xml in the extracted Sandbox zip file from destination environment (i.e Master_Sandbox_Destination folder). You can look for <mds:insert> elements with the app instance form name of the application being migrated
iii. Zip the Sandbox folder Master_Sandbox_Destination folder and import it to the destination environment using Sandbox manager in OIM sysadmin console
iv. Publish the Sandbox imported in the above sub-step
The above process represents the steps to be followed for one application and can be easily replicated for large set of applications. To expedite the process, we have created custom accelerators to automate the integration of applications in batches.
The ‘Disconnected Application Framework’ in OIM 11g can be leveraged to quickly integrate applications for manual provisioning. However with large number of applications to be integrated in a short span of time, without forethought and planning it can become a challenge to create and migrate the applications between environments. Following the process described above allowed us to avert most of the challenges and achieve a smooth application integration.
Coming in the next post:
While we all understand that OIM solution holds the keys to the kingdom of security in an enterprise, there is a growing need to ensure your OIM deployment is secure due to ever increasing rate of insider threats. One of the ways to secure all communication channels to/from OIM is via SSL. It's a common practice that in enterprise class deployments OIM is front-ended by a web server/load balancer. While typically the communication between the end users and web server/load balancer is secured via SSL sometimes securing the channel between and OIM and web server/load balancer or SOA is overlooked.
In our next post we share our experience with implementing SSL between OIM and load balancer & SOA in one of our recent implementations of OIM 11g R2 PS1, challenges to expect and relevant resolutions.
About the Author
||Rajesh Gaddam is a Senior Technology Architect with the Enterprise Security & Risk Management (ESRM) practice at Infosys Limited. He has over 10 years of experience in architecting, designing and implementing IAM solutions for multiple clients from different verticals.
|Rajesh can be reached via LinkedIn