Virtual Identity Dialogue

An unknown secret with Oracle Directory Services is that we have two ways to virtualize data stored in a database as LDAP.

One of course is via Oracle Virtual Directory's Database adapter.

The other is Oracle Internet Directory.

My focus on this post is to help provide guidance on the purposes of each option.

OVD Database Adapter
The OVD Database adapter uses Java's JDBC specification to connect to databases. This basically means anything with a JDBC interface is fair-game to connect to.

The OVD adapter is best suited for cases where you have existing user identity information stored in a database that you need or wish to expose via LDAP without needing to copy the data from the database into another repository.

This simplifies the management and reduces the time needed to implement such a solution. We have several customers that use OVD for this including ones with million or more user entries.

Another reason to use the DB adapter is if you have large LDAP Groups to manage and you want a more efficient mechanism to manage group membership than LDAP updates. By storing groups (which effectively become name value pairs in a single table in the database) in the database, you can do updates via SQL statements, which when it comes to very large groups, can be more efficient than updating members (though OID's large group management is better than most other LDAP vendors).

OID
If you are familiar with OID - you might be wondering why I put OID into a post about virtualizing database as LDAP.

The reason is that OID stores all of its data into an Oracle database.

And occasionally we get requests from an OVD perspective like "I have new directory information to store and I wish to store it in a database". Usually this is because they have experienced DBAs and Database management practices around storage that they want to continue to use.

In this case - we recommend OID. This is because OID is optimized to store general purpose LDAP data (as opposed to exposing existing database data) within an Oracle database. General purpose LDAP data management in a database requires a specific optimized database schema and SQL. This is work we have done on OID over the past decade and it does it pretty well.

While in theory you could do the same thing with OVD's DB adapter - it's not going to be as optimized and require more work than if you just used OID.

Summary

Need to expose existing data in database as LDAP -- OVD
Need to store general purpose LDAP into database -- OID

A nice comment from my earlier post:

Rave (a very cool name! writes):
"Hi, Nice Blog! I am a newbie to OIM. What I understood from your post is that I am suprised to hear that OID can be used to virtualise LDAP data.... Is it similar to what we call integration of different LDAP directories? If yes.. then how is it virtual? Because what ever changes you make to one like e-directory (when import is used to integrate with OID) the same changes are reflected in OID."

First Rave - I'm glad you like the blog.

Second - It's a fair question. I had intended to use the blog post to help see how the message sounded so that I could clarify it.

While OID acts more like a "traditional" LDAP server (that is it primarily is about storing data as LDAP as opposed to fetching it from existing repositories on demand) - it does so using SQL calls to a database. This is a different approach to traditional flat-file database approach. In particular because OID leverages Oracle DB - OID avoids the scalability and data management problems the old flat-file storage-based LDAP servers face.

So if you are facing a problem where you need to store some data into an LDAP server *and* you want to have that data stored in an Oracle Database - as opposed to exposing *existing* database data as LDAP - then OID is a better solution.