OIM 11g R2 Delegated Administration Model – Sample implementation (Part II)

Introduction

This article is the continuation of Part I which describes the architecture of a Solution that addresses the requirements of a Sample Use case described later.

In Part I, some key concepts were discussed. Below is a list of topics introduced in Part I of this post:

·         Scoped Administrative Roles

·         Access Policies

·         Disconnected Application Instance

·         Entitlements

This list is intended to serve as a reminder to the audience of the concepts comprising the foundation of the proposed solution.

This post will focus on the following use case:

A Real-Estate Company needs to implement a Provisioning solution to control access to the company's applications. Users log in to an application and are granted access to the application’s features based on group memberships in LDAP groups.

The company has hundreds of LDAP groups controlling what users can do within applications; individual assignment of those entitlements would be highly impractical.

In addition, the company is about to complete three acquisitions and needs to be able to quickly incorporate the new assets to the provisioning framework and start controlling access grants for the new employees coming over from the acquisitions. This is very complex to achieve since the acquired companies have their own directories which will not go away overnight.

Part III will provide the step by step instructions on how to address the requirements.

The importance of "orclguid" in Oracle Virtual Directory

This post will discuss the steps to configure the orclguid within Oracle Virtual Directory (OVD).  It is especially important when integrating OVD with Oracle Access Manager (OAM) and Weblogic Server (WLS).  I see many customers omitting this configuration which leads to errors in OAM.  


Background

All Lightweight Directory Access Protocol (LDAP) repositories contain a global unique identifier (guid) for every entry.  OVD is no different; it also has a guid object called the orclguid.  When configuring OVD with LDAP repositories it is important to map the LDAP's guid object with Oracle's guid object.  This however, is not configured by default.  In order to do this you will need to configure the VirtualAttribute plug-in for your adapter.

For more information please take a look at the OVD plug-in section in the documentation.

Forgetting this step may cause errors with respect to a) Authentication Failures and b) Identity propagation. For example, in Active Directory (AD) the guid object is called objectGuid, if this is not mapped to an orclGuid you will have issues when trying to propagate the users identity.


High-Level Steps

Once you have determined what the guid object is for your back-end LDAP repository, you will need to use the VirtualAttribute plug-in to map the two attributes. In our example above, the mapping will take the form: 

orclguid=%objectguid%

where objectguid is the guid object for AD.

If you have multiple LDAP back-ends, then you will need to configure the VirtualAttribute plug-in for each one.  Below are some screen shots that shows where you need to configure the plug-in.

Select the plug-in tab within the Adapter configuration...

Create a new Virtual Attribute plug-in with the parameters shown...

The OVD Provider in WLS, the 'orclguid' is already set as the GUID Attribute.   If not, make sure that the value of 'orclguid' is listed as below...

That's it!  The 'orclguid' will now be passed to OAM/WLS for each object with OVD.

Creating a Custom OVD Plugin

1. Introduction


In a recent engagement, I worked with a customer that had a business requirement where they needed to create and expose to their application two computed LDAP attributes, based on the value of an existing attribute.

For instance, let’s say the original attribute is "myCorpID" and its value could be something like "23451588-IT Specialist".

The requirement is to have two new defined attributes: "jobCode" and "jobTitle", that would have values "jobCode=23451588" and "jobTitle=IT Specialist".

To achieve this we would use OVD, which was already in place to virtualize different LDAP directoriess and databases.

OVD does not come with functionality out of the box to implement this requirement but does allow you to write custom plugins, where you can extend the capabilities of OVD to include requirements such as the one my customer had.

This post shows how to develop a custom OVD plug-in.

This plug-in reads a LDAP Object’s attribute value, splits the value in two, using a delimiter, and creates two new attributes with values assigned from the split operation.

Though this is a very simple requirement, and in fact my customer requirements were more complex than that, it can be used as a starting point to develop different use-case needs.

This plug-in is designed to work with a LDAP Adapter, and will run it’s logic for each LDAP "get" operation, before handing the result back to OVD.

The plug-in is flexible enough to work with any LDAP "objectClass" that has an attribute of String data type with a pattern delimiter that can be split in two.