Developing A White Pages Service with LDAP and JNDI
Attributes
An attribute of a directory object is a property of the object. For
example, a person can have the following attributes: last name, first
name, user name, email address, telephone number, and so on. A printer
can have attributes like resolution, color, and speed.
An attribute has an identifier which is a unique name in that
object. Each attribute can have one or more values. For instance, a
person object can have an attribute called LastName.
LastName is the identifier of an attribute. An attribute
value is the content of the attribute. For example, the
LastName attribute can have a value like "Martin".
Searches and Search Filters
You can look up a directory object by supplying its name to a
directory service. Alternatively, many directory services support
searches for objects based on properties, not just names. You can
supply a query consisting of a logical expression in which you specify
the attributes that the object or objects must have. The query is
called a search filter. This style of searching is sometimes called
reverse lookup or content-based searching. The directory service
searches for and returns the objects that satisfy the search
filter.
LDAP
Directory services are very common these days. There already exist
a plethora of directory service implementations:
- Novell Directory Service (NDS)
- Network Information Services (NIS/NIS+)
- Windows NT Domains
- Active Directory Services (ADS)
Accessing a directory service and manipulating its objects used to
be complex and difficult. The traditional protocol is X.500, a set of
directory recommendations specified by the International
Telecommunication Union. X.500 was enormous and complex.
LDAP is a direct descendant of X.500. LDAP was designed at the
University of Michigan to simplify access to X.500 directories (hence
the "L" for "lightweight" in "LDAP"). LDAP was designed to be
powerful enough to solve basic problems in accessing a directory
service but simple and light enough so more people can afford to use
it.
LDAP, currently at version 3, is now a standard for directory
information access. Many companies, including Microsoft, IBM, Novell,
Computer Associates, and Sun, have agreed to support it. LDAP is now
being used as an important part of a variety of services:
authentication systems, mail systems, and e-commerce applications. To
date more than 60 LDAP server implementations have been released;
approximately 90% of which are standalone LDAP directory servers, 10%
of which are components of other applications.
You probably already have an LDAP-aware client installed on your
computer. Many email clients can access an LDAP directory for email
addresses, including Outlook, Eudora, Netscape Communicator, QuickMail
Pro, and Mulberry.
The LDAP naming convention orders components from right to left,
delimited by a comma. LDAP arranges all directory objects in a tree,
called a directory information tree (DIT). Within the DIT, an
organization object, for example, might contain group objects that
might in turn contain person objects. When directory objects are
arranged in this way, they play the role of naming contexts in
addition to being attribute containers.
Standard LDAP Operations
In addition to client connections and disconnections, an LDAP
server must provide the following:
- the ability to bind to the LDAP server;
- the ability to add, modify and delete an entry; and
- the ability to search the server for these entries.
Note that the term binding in LDAP is different from its generic
directory services meaning. Binding here refers to the authentication
that a user is required to perform before accessing an entry in the
directory.