Apache Directory

From Bauman National Library
This page was last modified on 28 December 2016, at 10:32.
Apache Directory Server
Developer(s) Apache Software Foundation
Stable release
2.0.0-M20 / {{|2015|05|02}}
Repository {{#property:P1324}}
Development status Active
Written in Java
Operating system Cross-platform
License Apache License 2.0
Website http://directory.apache.org/

Apache Directory is an open source project of the Apache Software Foundation. The Apache Directory Project provides directory solutions entirely written in Java. These include a directory server, which has been certified as LDAP v3 compliant by the Open Group (ApacheDS), and Eclipse-based directory tools (Apache Directory Studio).

There exist these subprojects:

  • Apache Directory Studio - is LDAP-browser / editor for the data circuits, the LDIF and DSML, are written on the Eclipse framework.
  • Apache eSCIMo - a Java-based implementation of SCIM protocol.
  • Apache Fortress - for access control application, written in Java.
  • Apache Kirby - a Kerberos implementation is written in Java.
  • Apache LDAP API - this SDK to access the directory in Java.
  • Apache Mavibot - is a database application for Java-based applications


The core ApacheDS is a directory service that can store application data and perform searches for different types of data. Protocol implementations work on top of the directory service for Internet-services relating to data storage, search and retrieval. Perhaps the most important characteristic ApacheDS is the ability to use different protocols in its directory service. This means that you can keep your application data (including dynamic Java object) in ApacheDS, and different clients can use your data using various protocols. The most important protocol implemented by ApacheDS is Lightweight Directory Access Protocol (Lightweight Directory Access Protocol Catalog) (LDAP). ApacheDS acting as LDAP-server, listens for requests and coordinates with internal core directory service to respond to LDAP requests

Directory Sub-Projects

Apache Directory Studio

Apache Directory Studio is a complete directory tooling platform intended to be used with any LDAP server however it is particularly designed for use with ApacheDS. It is an Eclipse RCP application, composed of several Eclipse (OSGi) plugins, that can be easily upgraded with additional ones. These plugins can even run within Eclipse itself.


ApacheDS is an extensible and embeddable directory server entirely written in Java, which has been certified LDAPv3 compatible by the Open Group. Besides LDAP it supports Kerberos 5 and the Change Password Protocol. It has been designed to introduce triggers, stored procedures, queues and views to the world of LDAP which has lacked these rich constructs.

Apache eSCIMo

The Apache eSCIMo is a Java-based implementation of SCIM v2.0 specification. Using eSCIMo user and group details can be transferred easily between SCIM aware applications.

Apache Fortress

Apache Fortress is a standards-based access management system that provides role-based access control, delegated administration and password policy services with an LDAP backend.

Apache Kerby

Apache Kerby is a Java Kerberos binding. It provides a rich, intuitive and interoperable implementation, library, KDC and various facilities that integrates PKI, OTP and token (OAuth2) as desired in modern environments such as cloud, Hadoop and mobile.


The Apache Directory LDAP API is an ongoing effort to provide an enhanced LDAP API, as a replacement for JNDI and the existing LDAP API (jLdap and Mozilla LDAP API). This is a "schema aware" API with some convenient ways to access all types of LDAP servers, not only ApacheDS but any LDAP server. The API is OSGI ready and extensible. New controls, schema elements and network layer could be added or used in the near future.

Apache Mavibot

Mavibot is a Multi Version Concurrency Control (MVCC) BTree in Java. It is expected to be a replacement for JDBM (The current backend for the Apache Directory Server), but could be a good fit for any other project in need of a Java MVCC BTree implementation.


Alex Karasulu founded the Apache Directory Project project in 2002. In 2006, he was certified by the Open Group to be compatible with LDAPv3 protocol. In addition to LDAP, Apache DS and Kerberos5 Supports password change protocol. The developer is positioning as an embedded server solution designed for integration into other Java-based applications and to work with them in the context of a virtual machine. Today, it is built into products such as Apache Geronimo, JBoss and others. However, Apache DS can run autonomously, for example, as a service Windows. Since the program is written entirely in Java, it successfully compiles and runs on a huge number of hardware and software platforms. The project's website is available installers for GNU / Linux, Windows and the MacOS, and a package for the binary Debian, Fedora and Solaris (for SPARC and Intel platforms), but is actually a set of supported operating systems is much wider. In addition to standard LDAP server functionality in Apache DS implemented such interesting extension as stored procedures and triggers. Author of the project Karasulu Alex (Alex Karasulu) in 2001 suggested that the OpenLDAP server to support these facilities, which have long been used in relational databases, but not in the LDAP specification. His attempt failed due to the complexity of the existing software. In October 2002, Alex begins to develop its own directory server, written in Java. Then, in October 2003, he transfers his rights to develop code in Apache Software Foundation.

Directory services in ApacheDS

A directory service is an application that stores and organizes data. Directory service handles data that does not require frequent updates, such as personal data of users of the system (for example, name, address and phone number) or technological possibilities of production capacity (such as the number, types and production capacity of the installed equipment).



The Apache Directory Server (aka ApacheDS) architecture has many different layers. The following schema expose the most important ones :


As we can see, we distinguish four different layers :

the network the Session the PartitionNexus the Backends

Server startup

So when the DirectoryService has been started and is operational, we can start the various servers, which will accept incoming requests from remote peers.


It allow connection through the definition of transports. A Transport is a TCP or an UDP socket capable of absorbing a request and to send a response. Depending on the type of server, we may declare one or more TCP Transports, or a TCP and a UDP Transports, or an UDP Transport only.

Ldap Server

The LDAP server needs one or two TCP Transport. The standard LDAP port (defaulting to 10389 for ApacheDS, but the well know port is usually 389), and one can also declare the LDAPS port (defaulting to 10636 for ApacheDS, but the well know port is usually 636).

Note that *LDAPS* is considered as deprecated.

Kerberos Server

The Kerberos Server uses one TCP Transport (defaulting to 60088, but the well know port is 88 ) and one UDP _transport (same value for both ports). The idea is that the communication starts on TCP and continues on UDP.

ChangePassword Server

The ChangePassword Server uses one TCP Transport and one UDP transport, too. The default value is 60464, but the well known port is 464.

Http Server

It have a HttpServer running too, it's used for management. The declared ports are both TCP port, one is for HTTP and its default value is 8080, the other one is for HTTPS and its default value is 8443.


The DirectoryService is the core of the server. This is where we process incoming requests and ask the backend for data.

It has an entry point, the OperationManager, which is in charge of pushing the requests into the Interceptors chain, and to protect the server against concurrent modifications.

Then the request is going through every Interceptor being registered for this operation. When we have gone through all the Interceptors, we have reached the PartitionNexus, which is the connection with the backends.

We now just have to determinate which type of Backend we should address, and this is done using the Dn. The request is then transmitted to the Backend, which returns the result.

The result bubbles up through the Interceptors as we unfold the stack stack, up to the OperationManager and to the caller.


The DirectoryService knows about its execution environment : it has a schemaManager instance, it knows about the Interceptors chain, it stores a map of all the pending requests (it's necessary as one may abandon some request), it holds the existing Sessions.

In other word, the DirectoryService is not only the part of the server executing the logic, it also holds the current state of every clients.


Interceptors are functional layers inside the DirectoryService. Each one of them are responsible for a specific task. They are ordered, and this order is not to be changed.

Each operation rceived by the DirectoryService will be processed by various interceptors, one after the other, down to the backend, and again when the result comes back to the caller. An interceptor can call the next interceptor, whcih will be determinated by the position it has in the chain of interceptors, or simply return. Note that calling the next interceptor does not require that you know which one will be called.

Some Interceptors can be disabled, some other can be enabled. It's also possible to add some new one.


The Backend is the part of the server responsible for storing data in a way we can easily retrieve them. This storage does not necessarily have to be remanent : it can have a in-memory backend.

Existing Backends

it have 3 different backends :

JDBM LDIF In-Memory JDBM Backend

The JDBM backend is storing data on disk, using BTrees. It's fast when it comes to retrieve data, slow when you have to add them.

In-Memory Backend

This Backend loads in memory a full set of entries. ALl of them must be hold by the existig memory, we don't write on disk anything nor we read anything from disk. If the server is stopped, everything is lost.

LDIF Backend

It comes in two forms : one single file, or many fles (one per entry). It's always backed by a in-memory Backend, otherwise it would not be possible to retrieve the entries.

As we depend on a in-memory backend, which handles the indexes, we have to create those indexes when this Backend is read, which can be a costly operation.

ApacheDS performs JNDI

In the figure below you can see how ApacheDS performs add-naming and directory arrangement (Java Naming and Directory Interface - JNDI- a set of Java API, organized as a directory service that allows Java-clients to open and view their names and data objects ). for its core directory service. JNDI is a Java interface that defines methods to perform such actions as keeping directory data in the directory and search for stored data. JNDI is part of a Java 2 Enterprise Edition (J2EE), and the Java 2 Standard Edition (J2SE). Whereas J2SE only includes customer support JNDI, J2EE containers typically include a server-side implementation of JNDI. A J2EE-container can use the directory service via JNDI ApacheDS superstructure.

The set of interfaces in JNDI provides an abstract image of the directory service. Implementation JNDI provides the logic to communicate directly with a directory service (for example, Java-platform includes a JNDI implementation for LDAP). You can use JNDI to communicate with any type of directory service, if you have a JNDI implementation for exactly this type. If you want to use JNDI in a client application based on Java, you need a client implementation of JNDI. The client JNDI implementation provides classes that implement JNDI interfaces to author requests for directory operations. ApacheDS implements server JNDI. That means it includes classes that implement JNDI interfaces to reply to requests for directory operations. J2EE container can use the directory service ApacheDS through its JNDI-superstructure.

Built-protocol support

ApacheDS intended for use only as a directory service that is embedded in a J2EE container. You can use ApacheDS to implement any protocol that requires a protocol of internal service. You can even use it to serve different types of protocols at the same time; for example, the current ApacheDS implementation implements both LDAP, Kerberos and. Moreover, the list of protocols supported in ApacheDS is constantly growing.

As can be seen from the figure, ApacheDS uses a set of interfaces, called Multipurpose Interfaces for Networked Applications (Multi-purpose interfaces for network applications - MINA). MINA supports the implementation of a new protocol for implementation in ApacheDS.

How does MINA works

The interfaces in MINA contain methods to generate protocol-specific production facilities. These factory objects provide a means of implementing the new protocol implementation in ApacheDS. protocol implementations provide performance MINA interfaces, and the ApacheDS infrastructure based on the methods included in MINA to communicate with the implementation of the Protocol. For example, there MINA ProtocolProvider interface that uses getCodecFactory () method. This ProtocolProvider.getCodecFactory () method sends the object is exposed to a different interface MINA, namely ProtocolCodecFactory. Protocol implementations in ApacheDS ensure compliance ProtocolProvider interface. For example, LDAP implementation in ApacheDS has LDAPProtocolProvider class that implements the interface ProtocolProvider. getCodecFactory () method in LDAPProtocolProvider provides an object that exposes ProtocolCodecFactory interface. It ProtocolCodecFactory, which is a factory object and that ApacheDS framework uses to encode and decode objects for LDAP. ProtocolCodecFactory newEncoder include () and newDecoder (), which give the objects exhibited MINA interfaces and ProtocolEncoder ProtocolDecoder. The encoding object exposes the interface protocol specific ProtocolEncoder, and the decoding object exposes ProtocolDecoder interface.

Encoding and decoding MINA

Infrastructure uses ApacheDS class ProtocolDecoder particular protocol instance to decode a protocol request so that you can recognize it before you start processing the request. After decoding, ApacheDS processes the request. For example, if the request was a search for LDAP, ApacheDS would search for the requested data in the internal directory service and sorting of search results. After finding the desired search results, ApacheDS framework uses a specific object ProtocolEncoder protocol to encode the search results. In the case of search LDAP ApacheDS would use the LDAP object for ProtocolEncoder encode the search results before sending the answer to the author of the request.

Infrastructure Services MINA

MINA also has classes to handle services. Any system service can sign up for the registry service, and protocol access system will be recorded along with the classes access system, which provides the service. Then access protocol system converts queries protocol in JNDI action. A simple example is an LDAP search query converted to JNDI lookup action. Once the ApacheDS infrastructure recognizes what action you need to run JNDI protocol during query processing, it can generate an event. Infrastructure developments in the treatment of MINA sends the event to the appropriate handler. For example, if the request requires a JNDI search start action starts the search handler. MINA supports the drive to create the process. If a processor is busy executing a previous operation, the event is temporarily stored in the accumulator generated by the process as long as it will not be processed. You can see the access protocol system, MINA interfaces and classes, and action handlers working with JNDI in Figure 2. Perhaps the main advantage is the use of infrastructure ApacheDS directory service general (JNDI) for different protocols to access systems. This means that you can use ApacheDS to expose your data to clients using various protocols. As one of the most important protocols supported by ApacheDS, it is an LDAP (and since you will be using ApacheDS primarily as LDAP-server for storing Java objects)

Overview of the LDAP

LDAP-protocol recognizes the request and response commands for the directory action. Directory Actions involve storage of new data in a directory, search and retrieval of the stored data, delete unnecessary data, update old data, and similar action. (See. The Resources for RFC 2251, the official description of LDAP that contains the query command and storage response, retrieve, update and delete data in an LDAP directory.) LDAP command, which you use to store new data (such as your existing Java-object) in ApacheDS, called bind (tie). It transmits the user data in an LDAP directory service, such as ApacheDS, and stores data in a directory (or stores). For LDAP imeeet not value physical location of data storage. Instead LDAP specifies the Distinguished Name (Unique Name - DN) for each account is stored in ApacheDS. Each DN must be unique within the service log. The existence of two accounts with the same DN impossible. You will learn about LDAP mechanisms used to ensure the singularity of each DN, LDAP search engine uses the DN names.


For Apache Geronimo, you must have Java

Setting java:

sudo apt-get install default-jre

It is necessary to define the variables JAVA_HOME, JRE_HOME, JAVA_OPTS. For this in ~/.bashrc write:

vi ~/.bashrc
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
export JRE_HOME=/usr/lib/jvm/java-7-openjdk-amd64/jre
export JAVA_OPTS=

Download from http://directory.apache.org/studio/downloads.html Apache Directory and install the downloaded package

sudo dpkg -i apacheds-<version>.deb

And run the startup script

sudo /etc/init.d/apacheds-<version> start

To work with the Apache Directory Server, you can use Apache Directory Studio

Download from http://directory.apache.org/studio/downloads.html Apache Directory Studio

Extract the downloaded archive

tar xvf ApacheDirectoryStudio-<version>.tar.gz

Go to the unpacked directory

cd ./ApacheDirectoryStudio/

Run ApacheDirectoryStudio


Create a new connection: LDAP->New Connection

Bind DN or user: uid=admin,ou=system
Bind password: secret

External links

  • ApacheDS-official site [electronic resource]: The official website ApacheDS / treatment Date: 12.28.2016. - Access: http://directory.apache.org/