Cyril's Identity Management Blog

In order to better understand when to use an LDAP proxy, here're two stories made successfull thanks to an LDAP proxy deployment:

In the first scenario, an organization operates a partially public LDAP repository : on the intranet side, LDAP client requests are very limited (to a few technical users and administrators), they can bypass the LDAP proxy. On the internet side, users need access to the repository from an LDAP browser, and their access rights depend on credentials they have to provide. Here, the LDAP proxy enforces filtering and access control, like a reverse HTTP proxy would in the Web world: The LDAP proxy requires the clients to present an X509 certificate, and based on its content, different rules apply. So, it offloads the LDAP back-ends from this task, and make them more secure by filtering the unwanted requests. Moreover, managing the access control ruleset on the LDAP back-end, while possible, would have been painful, and less flexible:

since LDAP access control rules lack any standard specification, it makes them harder to move from one directory vendor to another and they don't often replicate from one server to another, making them harder to maintain consistent.

In the second scenario, the LDAP proxy 's been deployed in an intranet, for two main reasons:

1. To hide the data repositories complexity (user data are spread accross different SQL, LDIF, CSV or LDAP repositories and the LDAP proxy stands between them and some client applications). This way, the applications only see the LDAP proxy, and they only need to talk LDAP.The proxy is in charge of dispatching the requests to the right data source and eliminates the need for synchronization between the back-end information systems.
2. To ease data migrations and organizational changes: LDAP schemas sometimes change, organizations merge and information system needs reshaping. Modifying each application to take new requirements into account would require lots of work and planification. Here, the LDAP proxy can act as a transformation and dispatch engine, to hide from the applications the data organization changes across repositories, thus making them almost seamless.

I recently did some searches on what was going in the LDAP replication world, and especially the efforts to adopt a common replication protocol between directory vendors, that would allow them to replicate between each others. In the world of legacy directory servers, no standard's been adopted, since there was little commercial interest at least. The LDUP series of draft is a good example of aborted works in that direction. But since we now have at least 4 open source LDAP directories out there (OpenLDAP, Fedora, Apache DS and OpenDS), new developments and open source LDAP replication protocols 've been proposed and try to emerge.

For example, the LDAP Content Synchronization Operation protocol (RFC 4533), also known as "syncrepl", while experimental, published since 2006, and implemented at first in OpenLDAP, 's finally been recently chosen by the Apache DS team, although it's not clear wether it's fully or partially supported. Moreover, syncrepl's not optimized as this protocol transfers all visible values of entries belonging to the content upon change instead of change deltas. Delta-syncrepl improves syncrepl on that point, but it's not yet been published.

On the other side, neither Fedora DS nor OpenDS have plans to implement this RFC, but Fedora DS can already synchronize with older SUN DS versions and Netscape directory server: see this.

So, it seems like things are going better but some work has yet to be done. Provisioning engines, meta-directories, LDAP proxies, virtual directories, dedicated synchronization plugins or custom synchronization procedures should continue to exist for a while ...

Hello (from San Diego bay, CA) visitor !

Here you'll find useful (hopefully !) pieces of information about the LDAP and identity management space, and what's going on in this world, from my perspective, as a consultant.

I'll try to maintain at least a weekly pace and feed this blog with my day to day findings. Feel free to leave comments I'll enjoy to read and reply.