Thursday, July 12, 2012

Simplifying OIM 11g Series (Chapter One)


Introduction
This is the first one in a series of posts dedicated to the design of tools that have the common goal of simplifying or enhancing the functionality provided by OIM 11g. As more and more customers implement OIM 11g, new challenges arise and new issues are uncovered. OIM 11g is a very powerful platform but given the complexity of the problems OIM tries to solve, we have to admit that the product itself is sometimes not the easiest to implement by customers. The tools described in this series of articles have the purpose of facilitating the implementation of advanced capabilities of OIM or enhance some of the features of OIM making them capable of fulfilling certain use cases that have been traditionally complex to implement (but nevertheless, always possible).
In this article we will cover the design of a framework that allows business users to define provisioning processes that include approvals, sophisticated approval request routing and advanced user interface customization capabilities. A reference implementation of this framework will be presented in subsequent posts along the series.

Overview

OIM 11g defines two types of processes: Provisioning and Approval Processes. Provisioning processes are defined in OIM’s Design Console, whereas the Approval Processes are implemented in Oracle’s SOA Suite via SOA Composites and BPEL. As you can imagine, customers now have to deal with the intricacies of BPEL and the corresponding tools set. In some cases, the customers don’t have the necessary skills set to be able to customize Approval processes to fulfill complex use cases. This tends to produce less than desired results because - if best practices are not followed properly - there is a strong chance that the end solution won’t perform as expected. Now, due to the fact that Approval processes are defined using SOA Suite artifacts, only experienced developers that understand JDeveloper will be able to implement any required customizations to the processes. Moreover, Approval Processes are the ones that are mostly associated to the business, so Business Users should be able to define the proper approval flows that make sense to their business.
So the idea here is to design a set of tools that can be run on top the OIM 11g’s engine that will allow business users to define provisioning processes and approval flows. In order to achieve this, the tool kit needs to have the following:
  • A set of components that will perform tasks required by the framework including:
    • A Pre-Populate adapter that supports multi-value attributes.
    • A SOA Composite that will execute provisioning tasks and request application roles used to provision resources (this will be explained in detail later on).
    • An XML Schema to represent provisioning process definitions in XML.
  • The GUI that Administrators and/or Business Users can use to define provisioning processes.
  • A set of hooks where developers can implement extensibility interfaces to extend the functionality of the framework and can be deployed through the interface mentioned above.

Framework Components

The first thing to be addressed is the definition of the components in the framework. So the best way I know to start defining such components is to make a list of the tasks that are part of a provisioning operation, here they are:
  • Capture User Data
  • Route Approval Requests
  • Provision Approved Resources
Capture User Data

In this case the method used to capture data is via forms. Whereas OIM allows for the definition of input forms these apply to resource objects that are to be provisioned. OIM has the following process to configure request based provisioning:
  • Connectors define a Data Set which could potentially be customized. A data set is an XML file that contains the definition of the fields displayed in an input form including the UI element used to capture the value for the field and other metadata that indicates to whom the field is visible, the type of value it accepts and whether it is mandatory or not.
  • The Data Set has to be imported into MDS to be usable for Request Based Provisioning. This is not done at the time the connector is installed, it is done afterwards. The reason for this is that Data Sets can be customized to fulfill particular requirements so it would not make sense to import a dataset by default until customers are certain that the out of the box Data Set will address their needs.
  • A provisioning form is still required for entering the data for the request. This is the input form that OIM allows administrators to design and it is used for the actual resource provisioning. This form can be pre-populated with information coming from a variety of sources, including OIM’s user profile attributes. This is one of the capabilities we intend to leverage in our solution with a few tweaks.
  • If the provisioning of a resource is subject to approval, then a request template configured with the proper approval process is necessary. This is also dependent on the data sets for the resources being imported to MDS.
As made evident by the description above, OIM has a bit of a complex setup when it comes to self-service request based provisioning. Even though the complexity is sort of justified for the sake of flexibility and feature richness, it can easily get out of hand. So the approach I am going to follow to simplify this configuration is the following:
  • In order to prevent administrators from having to import datasets to MDS just to be able to request a resource object I am going to use access policies in combination with out of the box roles and a customization used to manage multi-value attributes in OIM’s User profile.
  • There are already out of the box request templates to self-request role assignment which don’t need importing a data set. So I intend to leverage those templates for my implementation.
  • A specialized composite will be written to execute my version of a provisioning process which internally will generate requests for roles associated to each requested resource.  An approval process that can be easily defined by business users through a provided user interface will be executed by a customized SOA Composite generated using OIM 11g’s command line tools (I call this composite OIM’s Composite). OIM’s Composite invokes a Web Service that generates a representation of an approval routing in XML which is read by the configuration of the participants of the composite’s Human Task. This representation is generated based on the specification of the approval process defined by the business users.

Route Approval Request

As part of any provisioning process, approvals may be and are often required. An approval process that can be easily defined by business users through a provided user interface will be executed by a customized SOA Composite generated using OIM 11g’s command line tools (I call this composite OIM’s Composite).

OIM’s Composite invokes a Web Service that generates a representation of an approval routing in XML which is read by the configuration of the participants of the composite’s Human Task. This representation is generated based on the specification of the approval process defined by the business users.

In this manner Business Users don’t need to be experts in JDeveloper or even need a developer to implement approval flows because these can be defined using an intuitive user interface. These descriptors are stored on the file system so if working with a cluster of OIM Servers they need to be available on all servers, but this requires only copying the files and that’s it; no server restarts are necessary.


Provision Approved Resources

Since all we are doing is leveraging OIM’s advanced capabilities for automatic provisioning this is taken care of by the access policies and potentially a pre-populate adapter to support multi-value attributes. 

The idea is to have a role associated to each Resource Object/IT Resource combination so a policy can easily be defined for the automatic provisioning of a resource object instance connected to an IT Resource target. If child forms need to be populated the custom pre-populate adapter will take that information from a special table (part of this framework) that extends the user profile of OIM to support multi value attributes.

Summary

This first article describes a framework that has the goal of simplifying the use of OIM 11g's features in customer implementations. The article only covers the design of such framework, while subsequent posts will cover a reference implementation of the components described here that customers and partners can leverage to build a tool kit targeted to make OIM 11g implementations simpler.
 

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.