LDAP Directory Technology Review

The Directory schema has been designed in a way that all the important and least-updated data are kept there, with all the necessary frequently updated data held in the MySQL server.

The initial decision was to design the Directory Information Tree (DIT) separating the directory entries according to the company departments, as would logically happen when designing a system to work using a RDBMS backend.

However this approach would cause performance problems, as too many similar entities (i.e.: department staff) within the DIT would compromise performance on a number of business scenarios.

The “LDAP for Rocket Scientists” online publication at the ZyTrax Inc. website (see references) argues that Directory Schemas are typically very flat in structure, with only 2 or 3 levels of hierarchy.

User Entry Example Directory Information Tree (DIT)

The publication gives an example of a directory which holds employee information and argues that it is more efficient to use a single directory entry for all employees, as opposed to using multiple entries, each under each department.

Initially I designed the schema based on principles from the Relational Model. Although it seems like the best possible solution in terms of data integrity and normalisation, this schema creates unnecessary performance “overheads” to the system.

The following figure shows an attempt to develop an Entity-Relationship diagram for the entire system, which indicates the limitations of this method to map the entities and attributes required for the system to operate. The design includes additional entities not introduced to the deliverables, as the functionality could not be implemented within the time available for development.

Entity Relationship Diagram of the Entire System

Diagram Explanation:
Initially, the design incorporated entities involved in two different departments, as opposed to just one, the web development and the web hosting departments. The entities and relations on the left side of the Customer entity were experimentally included to illustrate how a single management system can provide functionality for both departments.

The entities and attributes to the top and right side of the Customer show all the entities involved for the operation of the system developed for the web hosting department. Only sample attributes were included in this schema design.

As can be seen on the diagram, the Domain Name entity has one-to-one relationships with four different entities, a relationship which must theoretically exist so that the ordering system can operate. A domain name has a its own entry in the Apache, MySQL, Bind and Qmail schemas, in addition to a reference in an attribute of the User schema.

Initial Directory Information Tree (DIT) Design

Figure 9 shows the initial schema designed for the OpenLDAP Directory. The entities were separated according to each department, with staff information being stored on a separate entity in each department, while information about the servers (MySQL, Apache, etc.) are stored in a separate tree (under ou=network). For simplicity reasons, only the web hosting and web design departments were only taken into consideration.

This design approach requires the server to look at multiple sub-trees in the DIT. If the query could get all the staff information from a single staff entry, it would require less network resources to locate and retrieve the results.

For example, considering the query to find the names of staff working for a particular project for the web design department, the following PHP code by utilising the LDAP client libraries available for PHP, we can determine the path followed by it to retrieve the data:

$ldap_host = "ldap://artzweb.net";
$ldap_port = "389";
$ldapconn = ldap_connect($ldap_host,$ldap_port);
$basedn="ou=designdept,dc=artzweb,dc=net";
$filter=" (&(objectClass=staff)(objectClass=task)(did=example1.com)) ";
$attributes = array("uid", "cn")
$sr = ldap_search($ldapconn, $basedn, $filter, $attributes);
?>

A different architectural model is required which would be less complex to implement.

Since directory servers are optimised for retrieving data rather than updating, sub-systems based on the relational model are suitable for departmental tasks which involve frequent database updates.