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