Before I begin, I want to point out that the documentation of ApacheDS does a good job concisely explaining the concepts addressed here, the tutorial Naming and Directory Concepts is also handy. I am adding something extra to explain the concepts—an analogy. Besides, I also want to briefly talk about LDAP authentication and JNDI.
- Directory service
- Naming service
- Lightweight Directory Access Protocol (LDAP)
- Java Naming and Directory Interface (JNDI)
Directory — a hierarchical database (DB) with a specific structure: names are associated with objects (such an association is called a binding), objects are associated with attributes. Just like a relational or any other DB, it can be represented in various ways, e.g., by data structure in memory, a file, etc.
Directory service, a.k.a. directory server — a database management system (DBMS) for directories.
Naming service — a DBMS similar to a directory service, but the managed hierarchical DB contains only bindings. The functional difference between a naming service and a directory service is that the former focuses on looking up and updating the stored bindings, while the latter additionally provides extensive search capabilities and updates of the stored object attributes.
So any directory service is also a naming service, but not vice-versa. DNS is the most known naming service that contains bindings between machine names and IP addresses. Another example is the naming service provided by a Jakarta EE server1 to allow access by name to various resources.
LDAP server — a directory server that supports being accessed via LDAP.
Nothing prevents existence of other vendor-specific protocols serving the same purpose. The situation of having a standard protocol is very different from what we have in the rest of the DBMS world, where each DBMS has its own protocol and a driver library (a client) implementing it (e.g., PostgreSQL JDBC Driver for PostgreSQL, Datastax Java Driver for Cassandra, MongoDB Java Driver for MongoDB).
Since organizations often keep user records in a directory service, it is a natural idea to use it for authentication. There are two ways one can implement authentication in an application via LDAP (excluding other nonstandard ways of authentication a specific directory service may provide):
- by using the
bindoperation that was specifically designed for this purpose (see also this specification for additional info about the authentication mechanisms provided by the
- by using the
compareoperation and comparing the provided and stored password hashes (salted hashing is incompatible with this approach, which makes the whole approach questionable).
Spring Security calls the former approach
and the latter one is called
Usually, authentication is not the only thing that an application wants, and other interactions with a directory service may be required.
Java Naming and Directory Interface (JNDI) — a part of the Java SE API Specification that provides API for working with naming and directory services and SPI for plugging in implementations of this API for different services (see also JNDI docs published by Oracle).
Both OpenJDK JDK and Oracle JDK have LDAP Naming Service Provider for JNDI
and LDAP and JNDI tutorial published by Oracle).
Spring LDAP provides a JNDI facade
to simplify interactions with an LDAP server.
Unlike JDBC with its
JNDI does not expose connections and manages them under the hood. In some cases, one may want to be aware of the connection management
and have some control over it. This connection management tutorial
explains how to do so for the LDAP Naming Service Provider for JNDI.
DNS, being a naming service, can also be accessed via JNDI, and both OpenJDK JDK and Oracle JDK
have DNS Service Provider for JNDI