Resurrecting The Java LDAP Centric API

LDAP server development and usage is on the upswing. As Java developers attempt to take advantage of the full capabilities of modern directory servers, shortcomings in the built-in SDK are more evident than ever. Neil and I believe its high time to resurrect the call for a Java LDAP client. Its been done in the past (Netscape SDK, Novell, and so on) though this round we're shooting for standardization via the IETF or better yet a JSR. Interested? Let us know what you think.

Proposal for a Java LDAP Application Programming Interface

The Lightweight Directory Access Protocol (LDAP, as defined in RFC 4510 et al.) provides a standard means of communicating with directory servers. It is commonly used in identity management, authentication/authorization, naming services, user/application configuration, and general data storage. There are a growing number of commercial and open source server implementations, and many enterprises and service providers are significantly increasing the use of LDAP in their web applications, desktop clients, and mission-critical infrastructure.

While LDAP innovation and development continues on the server side the same is not true of the client. Java SE and EE clients typically use Java Naming and Directory Interface (JNDI) to communicate with directory servers. This is primarily because JNDI and the accompanying LDAP SPI are embedded within Java SE and is rarely based on the merits of the API itself. JNDI is intended to be a generic interface for accessing very different kinds of data stores, and as such uses an abstract API. As a result, critical LDAP functionality is difficult to access and the developer experience is significantly impaired. For example:

  • The abstract nature of JNDI terminology is confusing for the LDAP neophyte. That is, the Java LDAP developer must learn 2 different vocabularies, LDAP and JNDI. For example, the terms "bind" and "unbind" have standard meanings in LDAP which are very different from the way those terms are used in JNDI. In addition, a given JNDI method may result in different LDAP operations based on the arguments provided (e.g., while most variations of the JNDI "search" method will result in LDAP search operations, one usage will result in an LDAP compare operation, which may have different semantics).

  • LDAP functionality can be enhanced through the use of elements such as controls, extended operations, and SASL mechanisms, and such extensions are frequently described in new specifications. JNDI does not provide an adequate mechanism for adding client-side support for these elements.

  • Standard LDAP idioms are difficult or exposed in a bizarre manner; e.g., failed operation codes must be parsed out of exception messages, search enumerations must be closed.
We propose the creation of a new Java API specifically designed for communicating with LDAP directory servers. An IETF draft addresses this subject and will likely serve as a starting point for future discussion as the the goal of this draft and our proposal are identical: a simple, developer-friendly interaction model for LDAP communication. In addition, the API should provide a convenient means of extending its functionality by adding support for new controls and extended operations as they are defined by various standards bodies. There have been successful implementations of the draft API in the past, but they were based on older versions of the Java language and as such did not not take advantage of recent improvements in Java performance and usability.

In many ways this API could provide for LDAP what JDBC has done for Java relational database clients. The beauty of LDAP is that it is a wire protocol, hence there is no need for vendor specific driver implementations. As such, a Java-based LDAP API could easily be self-contained and free of external dependencies, making it more immediately accessible to developers. Standardization will relieve LDAP vendors of the mundane and repetitive task of maintaining vendor specific client libraries and provide developers with a pleasurable LDAP experience.

Get the PDF proposal


This is a great idea, and I'm fully supporting it. However, I don't think that IETF is the right place for standardizing APIs, and even less Java API. You should consider going directly the JSR path. Ludovic

Posted by Ludo on March 23, 2007 at 01:28 AM CDT #

Othe comment, the PDF proposal is a link to the post in PDF format and not the Java LDAP API draft, as I was expecting. It's a little bit confusing.

Posted by Ludo on March 23, 2007 at 01:30 AM CDT #

Hi Ludo, for the moment we're simply proposing the creation of a specification in the same manner one proposes a JSR. That is, step 1) establish there is a problem, 2) get others involved (vendors) 3) write the draft. I agree IETF is a bit of an oddball for a Java client, though the only specification (albeit expired) addressing the matter is housed there. Thanks for the vote of confidence.

Posted by Trey Drake on March 23, 2007 at 01:48 AM CDT #

I agree a JSR would be a better option than the IETF and that it would be beneficial for there to exist an API standard that unlike JNDI maps directly onto asynchronous protocol-level LDAP operations.

"The beauty of LDAP is that it is a wire protocol, hence there is no need for vendor specific driver implementations." Of course, there may still be vendor-specific SASL mechanisms, SSL implementations and control/extension implementations.

Posted by Mark Wahl on March 23, 2007 at 07:18 AM CDT #

Must be something in the air. I'm looking at overhauling the C API as well. Still at the stage of identifying the problems, but I think it's well agreed that there \*is\* a problem... Will be interesting to follow the ideas here.

Posted by Howard Chu on March 26, 2007 at 09:23 PM CDT #

Aren't both JLDAP and the mozilla SDK based on the mentioned IETF draft? Both are pretty well maintained and have been around for years.

Posted by Marc Boorshtein on March 30, 2007 at 02:32 PM CDT #

I wouldn't say that the Mozilla SDK is well maintained. The last release was years ago. Howard Chu of OpenLDAP is involved in this initiative so JLDAP will be represented. As mentioned, the idea behind a common API is to standardize the API (the 2 above may be similar, but they are not identical), modernize the API with developer friendly Java features (Generics come to mind), and provide an API/implementation with an OSI approved license.

Posted by Trey Drake on April 03, 2007 at 08:23 AM CDT #

Fair enough. I'm also an openldap committer with contributions to jldap (primarily around allowing jldap to work with DSMLv2 and SPML). I'm also the original author of the jdbc-ldap bridge on openldap and would like to be involved. One question I have is will this be an LDAP only API or an LDAP and LDAP-Like service API? For instance, while DSMLV2 is a 1-1 with LDAP (for the most part) SPML is not. In order to build SPML into JLDAP I had to add a way to manage the way different IdM systems handle SPML authentication. In addition I had to map SPML identities to DNs. I'd hope to avoid trying to be the be-all api jndi needs to be but there are a handful of protocols in addtion to LDAP that would be useful to support.

Posted by Marc Boorshtein on April 04, 2007 at 04:44 AM CDT #

Did you see this post

Great insight into Active Directory. Too bad Sun is not at the table...

Posted by Roger on July 22, 2008 at 12:42 AM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed



« June 2016