As members of the Fusion Middleware Architecture Group (a.k.a the A-Team), we get exposed to a wide range of challenging technical issues around security and Oracle Fusion Middleware. We're using this blog to answer common questions and provide interesting solutions to the real-world scenarios that our customers encounter every day.
NOTICE: All our post and much more can now be found at http://www.ateam-oracle.com/category/identity-management/

Wednesday, August 22, 2012

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.

Friday, August 10, 2012

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:

oMulti-valued User
Profile Attributes: OIM_EXT_MV_UPATTR

oApproval Flow
Definitions: OIM_EXT_APPR_FLOW_DEF

oCustom User Input
Forms: OIM_EXT_CUSTOM_FORMS_DEF

·Web Services:

oApproval Flow
Execution Service

oDatabase Persistence
Services

·OIM Custom
Adapters

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