This is the second in a series of articles explaining the evolution of
existing network standards to support radically increased traffic, electronic commerce and time-critical
content on the webs of the future. These demands will fall on the Internet, on corporate LANs and
wide-area intranets, and on virtual private networks between organizations.
This article gives you an overview of the Lightweight Directory Access Protocol, LDAP, which
Netscape Communications Corp., University of Michigan and more than forty companies endorsed in April 1996 as a proposed
open standard for directory services on the Internet.
The problem of naming and addressing
of entities admits of no unique solution. At bottom, the problem is this: entity 1 must know the name
of entity 2 to exchange data with it, but how can it get that name unless it already knows it?
(Stallings)
Background
Directories are repositiories of network name knowledge, essential for navigating loosely structured data
like the Web. One type of directory common on TCP/IP networks is the Domain Name System, or DNS,
which is a globally-accessible table of domain names and their corresponding IP addresses. (The table can also
be stored locally, in the form of a HOSTS file, on each client; but it's easier to maintain a central server.)
DNS works great, but it requires users to know the domain name they want. Applications like e-mail and
network management can benefit from more natural directory entries that include, for instance, people's names,
type of service, or geographic locale. This is particularly true on the global Internet, where the address space
is growing exponentially; but it's increasingly true on wide-area intranets, as well.
This is essentially the problem solved in the pre-Net world with the phone company's White Pages and
Yellow Pages. Proprietary networks employ tightly-coupled directory services, such as Novell's NDS. In
open networking, these capabilities are provided for in an international standard called
X.500. Adoption of X.500, which has been around since 1988, has been slow
because of its complexity and the practical constraint that its client half, Directory Access Protocol (DAP), is
too fat to run on PCs. What the world needs, you might say, is DAP on a diet.
Enter LDAP: Lightweight DAP. Also known as X.500 Lite,
the protocol enables corporate directory entries to be arranged in a hierarchical structure that reflects geographic
and organizational boundaries. Using LDAP, companies can map their corporate directories to actual business
processes, rather than arbitrary codes.
LDAP directories are arranged as trees. Below the topmost 'root' node, country information
appears, followed by entries for companies, states or national organizations. Next come entries for
organizational units, such as branch offices and departments. Finally we locate individuals,
which in X.500 and LDAP includes people, shared resources such as printers, and documents. An LDAP
directory server thus makes it possible for a corporate user to find the information resources she needs
anywhere on the enterprise network.
The X.500 information model allows for non-hierarchical relationships, too,
in the form of aliases -- pointers from one branch in the hierarchy to another.
One of the most important features of both X.500 and LDAP is the ability to search for user-specified
resources. Note that this is completely different from the full-text searching prevalent on today's Web in
engines like Excite or Alta Vista. Directory searches are more like database queries than pattern-matching
operations.
X.500 and LDAP directories can be distributed among many servers called Directory System
Agents (DSA). You might think of these as the reference librarians in several libraries. Replication can be
used to synchronize the listings between DSAs. In addition, X.500 directories (not LDAP) can be
secured using public-key encryption and digital signatures. Each X.500 operation and result can
be signed to preclude tampering.
To get its fighting weight down, LDAP sacrifices some of its hefty sibling's power. It makes up for this
in four ways:
LDAP was designed to run over TCP, making it ideal for Internet and intranet applications. X.500 DAP
requires special networking software to access the wire.
LDAP has simpler functions, making it easier (and, presumably, less expensive) for vendors to implement
LDAP encodes its protocol elements in a less complex way than X.500, streamlining coding/decoding of
requests
LDAP servers take responsibility for "referrals" -- in effect, the 'librarian' saying "What you want is across
town." X.500 DSAs return this information to the client, which must then issue a new search request. LDAP
servers return only results (or errors), which lightens their burden and makes a sea of distributed X.500 servers
appear as a single logical directory.
Reference 4 shows some interesting results of comparative performance testing.
By almost every measure, LDAP wins. It's queries are from 1.5 to 14 times smaller than X.500's, which translates
to lower network traffic. Decoding a complex message took 38.4 seconds with DAP, 2.7 seconds with LDAP.
The source code for LDAP is roughly a third the size of X.500's.
Of course, these gains cost some functionality. LDAP's lack of rigorous security and signature features is
a problem for electronic commerce. where a lightweight global directory could shine. (Think Yellow Pages.)
A variety of DAP extensions, such as replication and the ability to specify result formats, are not yet in LDAP.
Nevertheless, the scrappy protocol is shaping up to be a winner. Let's see why.
Internet
Draft: LDAP Version 3 promises such enhancements as authentication, encryption, integrity (data can't
be modified once sent), replication and type-down addressing (search operations start to seek names as
they're typed).
I don't know how close U. Michigan, where LDAP was born, is to Marc Andreessen's alma mater, U. Illinois.
Close enough for a spark to have jumped over to Netscape, apparently. The Mountain View, CA company has
embraced the technology and rallied deep support for it across the software industry. Of special importance is
the fact that Novell and Banyan have announced plans to extend NetWare Directory Services (NDS) and
StreetTalk, respectively, to interoperate with LDAP. IBM, AT&T and the major Unix vendors have signed on
as well. This promises an unprecedented degree of seamlessness between dissimilar networks.
The advantages of a universal directory standard run deep. It enables changes in one LDAP-compliant
directory to be synchronized with others, including those made by different vendors. This will be a boon for
both business-to-business communications, and for wide-area intranets linking corporate campuses with
heterogeneous networks.
According to Eric Hahn, senior vice president of enterprise technologies at Netscape, the fact that major
companies are lining up behind LDAP assures enterprise customers of "true interoperability between directory
servers and applications, whether they are managing enterprise directories or searching out information across
the Internet." Netscape plans to support LDAP in future versions of Netscape SuiteSpot, and to build
LDAP-compliant address book and electronic mail applications into Netscape Navigator.
Finally, LDAP has the potential to radically improve web productivity and navigability. To integrate the
two technologies, RFC-1959 proposes to add an "ldap://"
resource to the URL syntax. An effective implementation of this idea would bring a measure of Dewey
Decimal sobriety to the terabyte jungle.
Those of you who noticed the absence of a certain software maker from this tea party get a gold star.
Microsoft has said it will support LDAP in a forthcoming version of Exchange, its messaging server. But
for Microsoft, LDAP is another in the growing list of open standards Netscape is using to gain mindshare
and shift the action from the desktop, where Wintel remains unbeatable, to the network.
Gordon Benett is the Founder and Editorial Director
of Intranet Design Magazine He has written extensively on corporate
webs, including Introducing Intranets (Que, June 1996), a primer for
IT decisionmakers. Mr. Benett welcomes comments at <gbenett@internet.com>.
Events
[
Home | Discussion Forum | How Do I... |
Lotus Notes Intranets |
Microsoft SharePoint |
Products |
Shopping
]
(