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.

Using execution context ID (ECID)

Execution context ID (ECID) is a unique identifier to correlate events or requests associated with the same transation across several components.

The ECID value for a particular request is generated at the first layer and is passed down to the subsequent layers. The ECID value is logged (and auditable) in each product involved in the transaction. ECID allows an administrator to track the end-to-end flow of a particular request across the product stack.

ECID are supported by OUD and can be used to track LDAP requests from the client down to the ultimate LDAP server processing the request (inclusing LDAP access layer/proxy if any).

When performing a LDAP operation, a client can pass a ECID using the LDAP control extension 2.16.840.1.113894.1.8.31 . This ECID is logged by OUD. The OUD server generates a ECID in case none is present in the incoming request.

ECID are logged in the “Oracle Access Logger”. By default, this logger is disabled. To enable it, run the command below:

dsconfig set-log-publisher-prop \
         –publisher-name Oracle\ Access\ Logger \
         –set enabled:true\
–hostname localhost\
–port <admin port>\
–bindDN cn=Directory\ Manager \
–bindPassword ****** \

Here is a sniplet of the Oracle access log:

[2012-08-16T16:10:26.770+02:00] [OUD] [TRACE] [OUD-24641559] [PROTOCOL] [host: prehnite] [nwaddr:] [tid: 25] [userId: sduloutr] [ecid:,0] [category: REQ] [conn: -1] [op: 80] [msgID: 81] [dn: o=example] [type: synchronization] MODIFY

The administrator can then search the logs using a particular ECID value. Audit logs can be queried for a given ECID through Oracle BI Publisher’s audit reports. For example, if you send an LDAP request to Oracle Virtual Directory front-ending Oracle Unified Directory, an ECID associated with the LDAP request is present in the OVD diagnostic logs and audit logs; similarly, when the query reaches OUD, OUD includes the same ECID in its diagnostic logs and audit reports.