OIM 11g R2 & X.509 authentication

OIM 11g R2 is out! This release brings a lot of new features and also improvements to existing features.

OIM authentication providers are among the ones that were improved. The improvements make easier to integrate OIM with SSO solutions (for both SSO products and custom SSO solutions).

The integration with OpenSSO is documented here. The integration with OAM is still a powerful solution for SSO and password management and it is documented here.

The improvements also bring the support to X.509 based user authentication. In previous 11g release, one would need to leverage a SSO solution like OAM to do such authentication. In R2, X.509 authentication can be directly configured in WebLogic. This post describes how to configure this authentication.

Simplifying OIM 11g (Chapter Two)

Introduction

This is the second article in a series of posts with the common goal of providing customers with ideas and techniques that can be used to simplify the use of advanced features of OIM 11g. In Chapter One of this series, we described the components of a framework that would allow users at all levels to configure OIM 11g features like Provisioning and Approval Processes, Approval Routing Functions and Custom User Input Forms. In this second article I will start talking about a reference implementation of the components of the framework described in Chapter One.

Overview

The components that will be covered in this article are:

·         User Input Forms for OIM user creation and resource request.

·         Approval Flow Design Interface

·         Approval Flow Execution Agent Service

The above mentioned components comprise the part of the framework that takes care of Provisioning including the specification of approval flows that will be executed by the custom composite application described in chapter one, which will be the approval process for the Self Assign Roles request template which is out of the box and doesn’t need additional dataset configuration and importing to MDS.

Foundation Components

Before delving into details about the implementation of the higher level components, there are some elements that we need to put in place to support the implementation of the higher layer components. So, we will start by defining the infrastructure elements needed as a foundation for the implementation:

·         Database Tables:

o    Multi-valued User Profile Attributes: OIM_EXT_MV_UPATTR

o    Approval Flow Definitions: OIM_EXT_APPR_FLOW_DEF

o    Custom User Input Forms: OIM_EXT_CUSTOM_FORMS_DEF

·         Web Services:

o    Approval Flow Execution Service

o    Database Persistence Services

·         OIM Custom Adapters

o    OIM Multi Valued Pre-Populate Adapters

Once these components are created, and we will discuss the structure of each one of them, then the higher level components can be implemented. These include the following:

·         Approval Flow Design UI

·         Custom User Input Form Design UI

·         Custom User Input Form Rendering and Execution engine

While the goal here is to describe a reference implementation of the framework, it is just that, a high level description of the architecture and the elements that need to be built and the responsibilities of each element/component. The audience can take these descriptions and come up with their own actual implementation. Since this is a framework, once it is built, it can be reused and evolved over time to meet more specialized requirements.

Foundation Components Specification

Now I will start discussing the design and specification of the Foundation Components listed in the previous section.

Database Tables

This section describes the schema of the tables that will support the functionality of the provisioning components of the framework.

Table OIM_EXT_MV_UPATTR

Description: This table stores the values of multi-valued attributes of OIM user profiles. This table extends the USR table to support user defined attributes as multi-valued.

Structure:

Name	Type – Length	Description
USR_LOGIN	VARCHAR(20)	This field contains the login id of the user whose profile contains the multi-value attribute.
USR_LINK_KEY	VARCHAR (6)	This field links the values of an attribute to the specific user profile.
USR_LINK_FLD_NAME	VARCHAR(30)	The name of the Field. This is the same value as the FIELD_ID column of table OIM_EXT_CUSTOM_FORMS_DEF described later.
USR_LINK_VALUE_ID	INT	This field contains the index of the values. This is also part of the primary key.
USR_LINK_FLD_VALUE	CLOB	Stores individual values in a sequence of values for the multi-value attribute.
USR_LINK_FLD_SIZE	INT	The amount of characters allowed in the field values.
USR_RO_NAME	VARCHAR(30)	The name of the Resource Object whose process form contains a child table that holds the values for this multi-value attribute. This field may be NULL if the multi-value attribute is not associated to any Resource Object.
USR_RO_CHD_TABLE	VARCHAR(30)	The name of the Child Table where the attribute values will be contained.

Table OIM_EXT_APPR_FLOW_DEF

Description: This table stores the definitions of approval flows. Basically the required data for these processes is merely the login IDs of users that should receive requests for approval. The structure of the table supports sequential approvals, parallel approvals and escalations.

Structure:

Name	Type – Length	Description
PROCESS_KEY	VARCHAR (6)	This is a unique ID for the process.
PATH_ID	INT	This field stores the sequence number of approval routes in an approval flow.
APPROVAL_SLIP	VARCHAR(500)	The field contains either a single Login ID or a comma separated list of login IDs which represents the list of approvers that will receive the request in the way determined by the ROUTING_TYPE.
ROUTING_TYPE	VARCHAR(20)	The type of Routing for the request. Valid values are: SEQUENTIAL or PARALLEL.
ESCALATION_TIME	VARCHAR(20)	This is the time it will take for the approver to process the request before it gets escalated. The value is formatted according to the W3C notation for durations. Example: P1D (means after one day or no response for the task). If NO-LIMIT is specified then the escalation policy will be set P365D (1 year).
ESCALATION_USER	VARCHAR(20)	The Login ID of the user this will be escalated to.
TERMINAL_APPROVER	VARCHAR(3)	This value indicates if this approver’s response terminates the approval flow immediately. Legal values are ‘Yes’ and ‘No’.

Table OIM_EXT_CUSTOM_FORMS_DEF

Description: This table contains the definitions of custom user input forms that are customizable via XSL style sheets. The contents of this table will be generated through a GUI created for this purpose.

Structure:

Name	Type – Length	Description
FORM_ID	VARCHAR (30)	This is a unique ID for the FORM.
FIELD_ID	VARCHAR(30)	This is a unique ID for a FORM Field.
FIELD_TYPE	VARCHAR(30)	The value of this field represents the HTML control that will be used to input the value of the field.
FIELD_IS_MV	VARCHAR(3)	Flag that indicates whether the field is Multi-Valued or Single Valued. Allowed values for this field are ‘Yes’ and ‘No’.

Web Services

In this section I describe the functionality provided by a couple of web services part of the framework’s implementation. Let me start by explaining the reason why web services are included in the picture. In OIM 11g, all operations associated to Approvals are carried out through Oracle’s SOA Suite. Some of the components that can be most naturally included in SOA Composite applications which represent Approval Processes in OIM 11g are Web Services. So not having Web Services would not make any sense at all. Also, the main purpose of emphasizing this point is to discourage the use of embedded Java in SOA composites specially when the implementation assumes that requests may not be approved for weeks at a time; I have come across some customers that have used OIM APIs in Embedded Java Tasks and have experienced PERM Gen issues on the SOA Server.

Approval Flow Execution Web Service

This web service provides the functionality of executing approval flows. Basically all it does is returning the next approver in line for a multi-approver request flow. The web service output includes the following:

·         Single Approver in turn

·         List of Approvers in a parallel flow

·         Approver for escalated request

The nextApprover value returned by this web service call is placed in the owner field of the human task for the next approval. The web service also returns the status of the approval flow to determine whether further routing must take place or the end of the approval flow has been reached. The composite will evaluate all these values to determine the appropriate flow.

Database Persistence Service

This web service will be generated out of entities associated to the above mentioned database tables. JPA entities will be created and a Session Bean will act as the session façade for the entity beans generated out of the database tables. The persistence service will be invoked from the various GUIs used to define Approval Flows, Input Forms and other framework configuration elements.

OIM Custom Adapters

We have several options for the implementation of adapters that will deal with the multi-value attributes in a user profile. So the easiest way in my view to implement this is to have a post-insert entity adapter that will do the following:

Extract the names of the attributes associated to the user in question by querying the OIM_EXT_MV_UPATTR table for the User Login Name of the user in question. The reason why we do this search if because at a given time a user may not have all the attributes populated, so only the attributes that have been populated are processed.

Extract the key of each custom multi-value attribute from the user profile. The value is used to link the user profile with the OIM_EXT_MV_UPATTR extension table containing the values for each multi-value attribute of each user.

Extract the values of each multi-value attribute that is populated for the user in question using the key obtained above.

Using the tcUserOperationsIntf, tcFormDefinitionOperationsIntf and tcFormInstanceOperationsIntf populate the corresponding child tables potentially linked to each attribute. The information required to call these API’s is stored in table OIM_EXT_MV_UPATTR for each user.

Summary

I intended to present a potential implementation of multi-value attribute support and a mechanism to simplify the request process and potentially provide a more flexible customization mechanism. In the next chapter of the series we will discuss the implementation of the configuration GUI’s and the design of the customization mechanism for the input forms based on XML/XSLT transformations.