Using OUD plugin for SAML authentication with OAM against users stored in SQLServer

Here is a practical example about how to use a custom OUD plugin to speed up deployment of an Identity Management solution for a fraction of the price compared to developing a custom connector:

The use-case is to enable SAML authentication as an IDP where some of the users are stored in a SQLServer database and some in AD (external users in DB, internal users in AD).

The customer is planning to have OAM authenticate the users and perform the role of a SAML IDP doing LDAP authentication for users stored in the database and Kerberos for the users stored in AD. In order to allow OAM to authenticate users that are stored in the database, OUD can be deployed as a RDBMS proxy thanks to the RDBMS workflow element feature, so that users stored in a database table are exposed as a LDAP tree that OAM will authenticate against.

Problem is with the password field in the database that is hashed in a specific way.

The trick is to deploy a custom OUD plugin component ahead of the RDBMS workflow element. That plugin is responsible for processing bind requests only. Upon reception of a bind request against a user stored in SQLServer, the custon plugin retrieves the user entry containing hashed password and salt, accesses the plain text password provided in the bind request, and performs the password comparison based on custom logic.

Design, dev and testing took me a couple of days, much simpler and cost effective than adding support for this new source in OAM/OIM.

Provisioning to OUD using the OIM connector for OUD

OIM provides an extensive list of connectors, including a connector to Oracle Unified Directory (OUD). OIM Connector for OUD is described at

The Lookup.LDAP.UM.ProvAttrMap lookup definition maps process form fields with OUD target system attributes. This lookup definition is used for performing user provisioning operations.

For the default user fields that you can specify or modify values during provisioning operations , see Section, “User Fields for Provisioning an OUD Target System.”

For example, the Process Form Field “Common Name” is mapped on cn on the OUD side.

Some specific Process Form Fields are mapped differently. For instance the “Login Disabled” Process Form Field is mapped to the __ENABLED__ keyword in the default mapping file. __ENABLED__ does not directly correspond to any OUD attribute. It is a keyword that is associated with an effective OUD attribute in the OUD Connector configuration, as described in The OUD attribute used to store account state is specified  by the enabledAttribute. By default, it is set to ds-pwp-account-disabled.

The same indirection mechanism apply to the NsuniqueID and Password Process Form Fields mapped to __UID__and __PASSWORD__ that are provisionned to the OUD attributes defined by uidAttribute and passwordAttribute(entryUUID and userPassword by default).