LDAP PROXY

Our Java based LDAP proxy server software aggregates data from multiples sources (LDAP directories, SQL databases, flat files (ASCII, CSV), and web services) and makes it available through the LDAP protocol.

It works as an LDAP specialized firewall, usually deployed on at least two nodes, to prevent from any SPOF.

It supports namespace handling and dispatches requests accordingly, enforces fine grain access control and protect your data sources against denial of service attacks. It also features both an in-memory and persistent cache, as well as load balancing and fail-over abilities.

Its modular and extensible plugin architecture relies on a transformation engine, it allows virtually any kind of  data conversion or manipulation, as well as development of new connectors.

In order to better understand when to use such solutions, here're two use cases for which we've successfully deployed an LDAP proxy:

  • In the first scenario, an organization operates a partially public LDAP repository: on the intranet side, LDAP client requests are very limited, they can bypass the LDAP proxy, on the internet side, users need access to the repository from an LDAP browser, and their access rights depends on credentials provided by the end users. 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:
    • 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 entity and eliminates the need for synchronization between the back-end information systems.
    • To ease data migrations and organizational changes: LDAP schemas sometimes change, organizations merge andinformation 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.

Our offer is based on market products (Penrose in open source and Sun DSEE otherwise), consulting and best practices acquired through years of delivery and practice.


2004-2014 - JANUA