Virtual Identity Dialogue

[Renamed the title]

In many, if not most, large organizations you will find that there are
multiple directories used. Sometimes this is because you have an LDAP
domain controller for different global regions or subsidiaries or it
could be that one directory is internal & the other is external
people (such as customers or partners).



However, you will discover that many LDAP enabled applications are not
capable of speaking to multiple LDAP servers. Instead they can only
speak to a single service.



So what do you  do?



You can deploy a Virtual Directory (such as Oracle Virtual Directory)
which allows you to deploy a single, stateless "directory router"
service that makes multiple LDAP servers appear as a single LDAP server
without the need to synchronize to a single master service.



The way this works is that the Virtual Directory has "adapters" that
connect to your LDAP servers. In the adapter you define a namespace,
normally as a branch in the Virtual Directory's namespace.



For example -- if the root of your Virtual Directory is
"dc=example,dc=com" - you would create a virtual branch as
"ou=ldap1,dc=example,dc=com" for your first LDAP adapter. The value for
ou could be whatever makes the most sense for your organization.



And it doesn't even have to match the namespace your internal LDAP server is actually managing.



The benefit of exposing your LDAP adapters as branches is that it
simplifies the processing the Virtual Directory has to do in order to
determine which LDAP server is best suited to anwer the request.



After you have configured your LDAP adapters (with Oracle Virtual
Directory, this can be accomplished with just a few mouse clicks),
you're ready to point your LDAP client applications at the Virtual
Directory.



Now when the client performs a search against the Virtual Directory,
the Virtual Directory will pass the search request to all adapters that
could possibly answer that request. And then pass it back to the client
all responses received from all adapters that responded with returned
entries. 



Thus your clients believe they searched a single LDAP server and got 1
or more entries. It has no idea that in reality those entries came back
from multiple LDAP servers.



And this applies to all types of LDAP operations including bind and add/modify/delete - not just search.