LDAP Data Model Design

Requirements:
1.  Have flexible schema
2.  Satisfy all the organization model
3.  Multi-Tenant
4.  Support evolvement and
5.  Define a good LDAP Schema

Research:
1.  LDAP is designed to solve this organization problem, and is used in mainstream

Protocols:
1.  X.500

Technologies:
LDAP
Active Directory
Apache Directory
WSO2
LDAP Java Client

Knowledge Sharing:
1.  LDAP directories are structured as a tree of entries, where each entry consists of a set of attribute-value pairs describing one object. The objects are often people, organisations, and departments, but can be anything at all. Schema is the term used to describe the shape of the directory and the rules that govern its content.
2.  A hypothetical organisation is described, with requirements for “white pages” directory service as well as a wide range of authentication, authorisation, and application-specific directory needs.
3.  A plan is proposed for the layout of the directory tree, with particular emphasis on avoiding the need to re-organise it later. This involves careful separation of the data describing people, departments, groups, and application-specific objects. A simple approach to entry design is shown, based on the use of locally-defined auxiliary object classes.
4.  LDAP can be used to access information describing people, organisations, roles, services, and many other sorts of entity. It is a standard and widely-implemented protocol, which makes it extremely valuable for integrating multiple applications that need to share common data.
5.  LDAP is a protocol - the Lightweight Directory Access Protocol. It isnot a database or even a directory although the term LDAP directory is often used to describe a directory service that is accessed using the LDAP protocol.

6.  An LDAP Directory stores information in a tree structure known as the Directory Information Tree (DIT). The nodes in the tree are directory entries, and each entry contains information in attribute-value form.

7.  Some attributes may have multiple values; others are restricted to a single value. The set of attributes that may be present in an entry is determined by the objectClass attribute,which is always present. objectClass is a multi-valued attribute and each value defines a set of mandatory and/or optional attributes.

8.  Each node in the DIT has a name called the Relative Distinguished Name (RDN) which is unique among the peer nodes under its parent. It also has a globally-unique name called the Distinguished Name (DN) made up from the name of the node itself plus the names of all its superior nodes up to the root of the DIT.

9.  Most current LDAP deployments are limited to operation within a single organisation, so although data replication is commonly used, the other features of the distributed service model do not get so much exercise.

10. When considering an LDAP deployment that is to serve more than one application, it is important to get the widest possible view of the host organisation and its future needs. This is because it is easy to change the shape of the DIT at the design stage but very hard once data has been loaded and applications are running.

11.  The usual solution to this problem is to list all people under a single node in the DIT.

12.  Most organisations have fuzzy edges, as the exact distinctions between “staff”, “contractors”, “suppliers”, “business partners”, “customers”, “visitors”, etc are not rigid or constant. It therefore makes sense to group all types of person into one place and to make any necessary distinctions by adding attributes to individual entries, or by using group objects.

14.  There should be one arc of the DIT for each application. The management of these subtrees can be delegated to the application managers. The LDAP service itself is a network application, so it should have a subtree in which to store groups used for access control etc.

15.  All information within a directory entry is stored as attribute-value pairs. The set of attributes that can appear in a given entry is set by its objectClass. Some of the attributes are mandatory, but most are optional. New attributes can be defined if necessary, and new object classes can also be added to permit the new attributes to appear in entries.

16.  it would be possible to add more permitted attributes to this object class and they would automatically become available in all the entries that use it. 

17.  Another useful trick is to avoid deleting entries when people leave: just set an attribute to say they are inactive. This can be useful where an audit trail is required but does introduce more complexity in ACLs.

18.  LDAP servers can be optimised for different forms of query by adjusting indexing and caching parameters, and in a large installation it is critical to get this right. 

19.  When building an LDAP directory it is important to consider all requirements and to plan carefully at the start, as re-organising the Directory Information Tree later is very difficult.

20.  

LDAP Design Principles:

1.  Once an object has been created in an LDAP directory it is likely that the name of that object will get stored in other objects, or even outside the directory entirely. This suggests that objects should never be renamed, which in turn restricts the choice of how they should be named in the first place.

2.   I recommend that all entries representing people or other entities that might change name should be given RDNs containing only the uniqueIdentifier attribute: the value can be a simple serial number, which does not have to mean anything outside the directory.

3.  It is thus a good idea to include displayName in every directory entry.

4.  Groups are normally represented by LDAP objects with the groupOfNames class. In these objects, group members are represented by member attributes, whose values are the DNs of the members themselves. The member attribute can obviously have multiple values. This is a simple scheme, but it does have two significant problems

5.  The initial loading and ongoing management of directory data is too big a subject to cover here. However, it is important to note that the directory schema may have to be extended to hold “foreign keys” so that entries can be correlated against other databases.

6.  

Vocabulary:

• CN = Common Name
• OU = Organizational Unit
• DC = Domain Component

Questions:
1.  What is an organization ?
2.  How to map the business requirements to LDAP Schemas ?
3.  

References:
http://www.skills-1st.co.uk/papers/ldap-schema-design-feb-2005/ldap-schema-design-feb-2005.html
http://en.wikipedia.org/wiki/X.500
http://stackoverflow.com/questions/18756688/what-is-cn-ou-dc-in-ldap-search