Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Java API specifications for LDAP-centric and directory-agnostic clients (2007/3/23)
Trey Drake, who returned to Sun as an OpenDS community manager, wrote yesterday in Resurrecting the Java LDAP Centric API that
"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."
I look forward to a Java API standard for developing LDAP clients that is not hindered by the limitations of JNDI. JNDI, the Java Naming and Directory Interface, was derived from the concepts of the Microsoft Open Directory Services Interface from 1995, now the Microsoft ADSI. Both ADSI and JNDI attempted to have a single interface to access multiple implementations of workgroup/enterprise account repositories. ADSI for example was intended to enable a client to find or create an account in any of an LDAP server, a Windows NT domain, or a Novell Directory Server. But these goals weren't achieved, as a client developed and tested with one underlying directory access protocol would likely not work when deployed in an environment using some other underlying directory access protocol. Furthermore, many of the protocols and directory services underlying JNDI and ADSI are becoming obsolete. We need an API that enables developers for building LDAP-based applications atop the Java platform. For example, client implementors that need to make use of LDAP controls and extended operations that aren't provided the JNDI must either
- write the client code for these (including finding their own library to implement the Basic Encoding Rules since this isn't exposed by JNDI), or
- be tied to an API of an alternate (non-Sun and non-standard) LDAP client implementation.
I hope that a JSR for the LDAP client side API can be agreed upon by the implementors of Java client libraries without too much controversy.
Separately, we also still need an API that achieves the goals of JNDI, but for today's identity systems. (A standard LDAP client API could be layered below this API). Two of the issues that must be addressed by such a higher-layer API include:
- there is a wider variety of protocol and deployment models being deployed today than were available for consideration when JNDI was designed.
For example, JNDI assumes a request-response DAP-style protocol interaction with a central server. Today, there is a wider spectrum of federation and decentralization.
- the schema problem, which JNDI never really addressed.
Later versions of JNDI provided APIs for schema discovery, by which a application could determine the current schema of a directory service with flexible/extensible schema, but didn't provide an API to deal with mapping an enterprises' choice of schema schemas onto an application's requirements, or extending the schema for application requirements that are not part of the enterprise schema.
Currently, many of these concerns are being considered in the design of the APIs of the Higgins project, which is developing components in the Eclipse framework for use in identity management clients.
"Using service adapters, existing and new systems such as directories, collaboration spaces, and communications technologies (e.g. Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be plugged into the Higgins framework. Applications written to the Higgins API can virtually integrate the identity, profile, and relationship information across these heterogeneous systems."
Higgins' planned architecture resembles:
