Synchronization vs Server Chaining
November 27th, 2007If you use an LDAP server for authentication, and work for a company with legacy applications, you have probably explored the option of LDAP synchronization. Particularly if you are using Oracle, the integration with OID is tightly coupled with the middleware applications. Historically, OID synchronization has been difficult to configure, has significant performance impacts, and requires regular monitoring of the replication.
In Oracle Internet Directory 10.1.4, there is a new option - Server Chaining. You can use server chaining to ‘virtually’ link to another LDAP Server. I have implemented this architecture so that we could take advantage of the Oracle integration with OID but also include a large group of users existing in an external LDAP server.
The actual server chaining takes about 5 minutes of configuration, and all of the users in the remotely mapped container appear in the local OID. Authentication via SSO is immediate - both OID and chained users authenticate seamlessly.
Group management can be done on both types of users, and this group membership is recognized by Oracle SSO-enabled applications including Portal. You can add a chained user to an OID group via OIDDAS or directly in the oidadmin utility. Presumably you could also include a local OID account in a remote chained group but I didn’t use this functionality.
There are some issues with server chaining though - the oracle OIDDAS interface throw an error if you log in as a chained user. You can log in as an OID account and search for the chained users, but there is some kind of error in the OIDDAS that just throws a proxy privilege exception and does not allow you to continue (or log out) once you have entered chained user credentials.
There are several Oracle and third party applications that use direct LDAP authentication, such as Application Express, Confluence, XML Publisher. These application generally require a specific realm within the LDAP server that is used for access. It is not recommended to map the chained users into the root realm within OID, so it is difficult to allow both chained and local users to authenticate into these ldap-direct applications. However, this would also not be possible in the original architecture since the users were distributed in the source LDAP.
The biggest issue I have experienced is that currently you can only chain one remote LDAP of each type (Active Directory and SunOne). It would be great if you could map to different ldaps, or have filter control on the mapping. Because our chained accounts were in many realms, we had to map at a very low level and degrade search performance on OID because of a lot of (unnecessary) account mappings.