The Lightweight Directory Access Protocol (LDAP) is a protocol for accessing online directory services. It runs directly over TCP, and can be used to access directory services back-ended by X.500, standalone LDAP directory services or other kinds of directory servers.

A Directory is like a database: you can put information in, and later retrieve it. But it is specialized. Some typical characteristics are: designed for reading more than writing, offers a static view of the data, simple updates without transactions. Directories are tuned to give quick-response to high-volume lookup or search operations.

A Directory Service sports all of the above, plus a network protocol used to access the directory. And perhaps also a replication scheme, a data distribution scheme.

X500

LDAP was originally developed as a front end to X.500, the OSI directory service. X.500 defines the Directory Access Protocol (DAP) for clients to use when contacting directory servers. DAP is a heavyweight protocol that runs over a full OSI stack and requires a significant amount of computing resources to run. LDAP runs directly over TCP and provides most of the functionality of DAP at a much lower cost. This use of LDAP makes it easy to access the X.500 directory.

In X.500, the namespace is explicitly stated and is hierarchical. Such namespaces require relatively complicated management schemes. The naming model defined in X.500 is concerned mainly with the structure of the entries in the namespace, not the way the information is presented to the user. Every entry in a X.500 Directory Information Tree, or DIT, is a collection of attributes, each attribute composed of a type element and one or more value elements.

The X.500 standard defines 17 object classes for directories as a baseline. Being extensible, X.500 directories may include other objects defined by implementors. The 17 basic object classes include:

• Alias
• Country
• Locality
• Organization
• Organizational Unit
• Person

Objects in these object classes are defined by their attributes. Some of the basic 40 attribute types include:

• Common Name (CU)
• Organization Name (O)
• Organizational Unit Name (OU)
• Locality Name (L)
• Street Address (SA)
• State or Province Name (S)
• Country (C)

Putting this all together, an unambiguous entry for an addressee would be specified by its distinguished name, say {C=US, O=Acme, OU=Sales, CN=Fred}

Sample X.500 hierarchy. Starting at the highest level, or Root, we can traverse the tree to successively lower levels, called Country, Organization, and Common Name, for instance.

Applications and users access the directory via a directory user agent, or DUA. A DUA transfers the directory request to a DSA, or Directory System Agent, via DAP, the Directory Access Protocol. The directory itself is composed of one or more DSAs. The DSAs can either communicate among themselves to share directory information or may perform what is called a referral, i.e., direct the DUA to use a specific DSA. Referrals may occur when DSAs are not set up to exchange directory information, perhaps due to lack of interworking agreements between the administrators, or for security reasons.

Support both chaining and replication (current LDAP products do not)

LDAP

• a network protocol for accessing information in the directory. It defines the operations one may perform e.g. search, add, delete, modify, change name. It also defines how operations and data are conveyed.
• an information model defining the form and character of the information
• a namespace defining how information is referenced and organized
• an emerging distributed operation model defining how data may be distributed and referenced (v3)
• Both the protocol itself and the information model are extensible

Any data types can be into the directory: Text, Photos, URLs, Pointers to whatever, Binary data, Public Key certificates.

Different types of data are held in attributes of different types. Each attribute type has a particular syntax. The LDAP standard describes a rich set of standard attribute types and syntax (based on X.500's set). Plus, you may define your own attributes, syntax, and even object classes -- you can tailor your directory to your own site's specific needs.

The information model and namespace

They are based on Entries. An entry is simply a place where one stores attributes. Each attribute has a type and one or more values.

Entries themselves are "typed". This is accomplished by the objectClass attribute.

The namespace is hierarchical, so it has the concept of fully-qualified names called Distinguished Names (DN).

Here, test Entry's DN is "cn=test entry, ou=people, dc=stanford, dc=edu"

Accessing an LDAP-based directory is accomplished by using a combination of DN, filter, and scope. A base DN indicates where in the hierarchy to begin the search. A filter specifies attribute types, assertion values, and matching criteria. A scope indicates what to search: the base DN itself, one level below the base DN, the entire sub-tree rooted at the base DN.

LDAP directory service is based on a client-server model. One or more LDAP servers contain the data making up the LDAP directory tree. An LDAP client connects to an LDAP server and asks it a question. The server responds with the answer, or with a pointer to where the client can get more information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service, like LDAP.

• LDAP is an extensive, vendor-independent, open, network PROTOCOL standard: so accessing data is done transparently across a highly heterogeneous network (i.e. the Internet).
• An LDAP-based directory supports any type of data.
• Can configure an LDAP-based directory to play essentially any role.
• The LDAP protocol directly supports various forms of strong security (authentication, privacy, and integrity) technology.
• Can use general-purpose directory technology, such as LDAP, to glue together disparate facets of cyberspace, e.g. email, security, white- & yellow-pages, directories, collaborative tools, MBone, etc.

The X.500 DAP protocol is seen as being complex, and hard to implement. LDAP offers a simpler model that fits more closely with the ideals of the Internet protocol suite.

Due to perceived in the widespread adoption of X.500, LDAP is now seen as the basic, simplest

form of protocol, around which other directory-based requirements can be defined.

LDAP is a specification of a protocol to allow users to access a directory. However, LDAP does not specify how the directory service itself operates.

This is a problem. Key service aspects such as controlling access to the data, and facilities for replicating the data (for redundancy and performance) are not included in the LDAP specification. Any operational directory system needs to provide these components.

Most of the vendors providing LDAP-based services have their own mechanisms for providing a directory

model, access controls and replication. Many of these will be similar to X.500, but not compliant with the

standard and may not be interoperable with products from other vendors, although it can be expected that

inter-working for involving the major vendors will address many of these problems.

• V3 Referrals
• Modify DN
• Schema support Extensible Match
• UTF-8

Any JavaTM application that needs to access information about users, machines, networks, and services. User information includes security credentials, phone numbers, electronic and postal mail addresses, and application preferences. Machine information includes network addresses, machine configurations, etc. In addition, any Java application that needs to either export objects or access objects exported by other applications and services. Examples include printers, calendars, and networked file systems.

Yes, JavaSoft will produce a reference implementation which consists of the JNDI framework combined with the necessary service providers for LDAP and NIS. Different naming and directory service providers can be plugged in seamlessly behind JNDI to enable access to the respective services.

IBM, Novell, Sun, HP and Netscape. Their implementation strategies may vary in order to support thin-client configurations and fat-client configurations.

JNDI provides an excellent object-oriented abstraction of directory and naming. Developers using JNDI can produce queries that use LDAP or other access protocols to retrieve results; however, they are not limited to LDAP nor do they have to develop their applications wired to LDAP. JNDI supports the key capabilities that are likely to be incorporated in LDAP v3.

• Accessing the Directory

A directory is typically used to associate attributes with objects. A person object,

for example, can have a number of attributes, such as the person's surname,

telephone numbers, electronic mail address, postal address, computer account, and

authentication information such as his password or X.509 certificate. Using JNDI, to

retrieve the email address of a person object, the code looks as follows.

Attribute attr =

directory.getAttributes(personName).get("email");

String email = (String)attr.get();

• Searching the Directory

An application can also use JNDI to search the directory for objects by specifying

some attributes. For example, to search for people whose surname is "Fox" in the Wiz

organization, the code looks as follows.

foxes = directory.search("o=Wiz,c=US", "sn=Fox", controls);

• Looking up Objects

An intuitive model for the Java programmer is to be able to lookup objects like

printers and databases from the naming/directory service. Using JNDI, to lookup a

printer object, the code looks as follows.

Printer printer = (Printer)namespace.lookup(printerName);

printer.print(document);

• Browsing the Namespace

When using almost any kind of interactive application that prompts the user for

input names, the user's job is simplified if a namespace browser is made available to

him. This browser can either be general-purpose or be supplied by the application.

Using JNDI, to list the contents of a particular level in the namespace, the code looks

as follows.

NamingEnumeration list = namespace.list("o=Widget, c=US");

while (list.hasMore()) {

NameClassPair entry = (NameClassPair)list.next();

display(entry.getName(), entry.getClassName());

}

In Habanero, we are using file storage to keep persistent all kind of information. Moreover, some of these data are duplicated on each local machine whereas they are the same. These data are:

• Information on yourself: Id Card. There is no Id Card database right now. Everyone share his/her own information when he/she joins a session.
• Information on how to locate participants to notify them to join a session. The Address Book Database.
• Information on Templates. A template is a set of information describing a session such as data about how to load/access the session, agenda and dates of the session, guests to invite in the session, session's security access, and MBone details.
• Information on Tools.
• X509 Certificate management for the Authentication system

These data should be stored in databases or directory services to avoid duplication of information. These data should be also accessible from different machines/configuration/etc…

By using LDAP to do so, we will benefit of its:

• Standardization and interoperability of accessing data over the net,
• Extensibility to support any kind of data,
• Support for "strong security"
• Popularity and adoption by others to access other information than the ones generated by Habanero. For instance, through LDAP we could access information about people ID or security certificates without asking them to reduplicate this information only for Habanero purpose.

Because the LDAP standard describes a rich set of standard attribute types and syntax and allows defining new attributes, syntax, and even objecting classes, we should be able to tailor our directories to Habanero needs. To investigate this topic, refer to RFC 1617: http://andrew2.andrew.cmu.edu/rfc/rfc1617.html

Nevertheless the structure of the directory service should be defined according to our back end choices and/or the availability of free LDAP-based services.

LDAP Implementations: Freely Available Software (from http://www.critical-angle.com/dir/liav.html)

As far as I investigated, I believe none of these free LDAP implementation are Java compliant.

1. We could reuse LDAP client tools to browse LDAP servers and get back the information that fulfills a request. Or include in the Habanero Server/Client a browsing tool that will connect to LDAP server via JNDI interface.

I think we should take a look at the second solution that seems easier and Java compliant.

2. Queries

The end user should be able to query several LDAP servers to be able to:

• Locate somebody on the net to notify him/her of an Habanero event
• Locate sessions responding to criteria such as a theme session, session type (MBone, audio, etc…), session name, etc…
• Select his/her own ID and security certificates before joining a session or in the session.
• Retrieve collaborative tools to download them from a server.

The system will also need to query LDAP servers in order to locate asynchronous participant, archived, live sessions to merge them, etc…

All these points can be viewed as 3 queries' categories: location of sessions, of users, and of tools according to criteria.

While finding solution for Habanero and LDAP we should keep I mind the we could use LDAP for X509 Certificates Management. To know more about how Netscape communicator deals with that look at http://developer.netscape.com/library/documentation/security/SSO/sso.htm.

• Java Naming & Directory Interface: http://java.sun.com/products/jndi/overview.html