DIRECTORIES AND LDAP

UNIVERSAL ACCESS TO DIRECTORY INFORMATION

By Caroline Rose, View Source staff

When you think of an information directory, you most likely envision a centralized database containing names, phone numbers, e-mail addresses, and other information about people in an organization. And no doubt you can easily imagine the advantages that having centralized directories offers to the people who use and maintain them. But do you know that directories are much more than just "white pages" or a method for finding e-mail addresses, and have you thought about what directories mean to you as a developer? If not, we'll give you some food for thought in this article - and if you already appreciate directory services but not the solutions that have existed to date, we've got some good news for you. LDAP (Lightweight Directory Access Protocol), the Netscape Directory Server, and Netscape's variety of client-side directory tools offer an opportunity that you won't want to miss out on.

WHO CARES?

If directories make you think "What city, please?", think again. They're not just about keeping track of phone numbers, e-mail addresses, and physical addresses. They can also track people's software configuration preferences, access privileges, group memberships, and calendar information, for exaample. And directories don't only store information about people; they can contain any type of information to be shared or centralized, like conference rooms or network resources (such as printers or fax machines).

To name only a few useful applications of directories:

  • Tracking users' software configuration preferences in a directory can give them the mobility they need to work from any location. Rather than being stored in a local registry or preferences file, accessible only from a single computer, this information can essentially travel around the network with the user.
  • Tracking access privileges in a directory enables network administrators to keep users out of parts of the network that are off limits to them. Storing access control rights in the directory enables multiple applications to have easy access to the same security settings.
  • Centralizing user account and password information can minimize password management and disparate sign-ons across applications.
  • Managing Web site configuration information in a centralized directory makes site administration simpler. One configuration change in the directory can easily be applied to all the servers at the site.
Having directories that follow a standard, open protocol moves applications and software vendors from a desktop-oriented focus to a network-centered one. Instead of being limited to looking up addresses in a local address book, users can search external directories that follow the standard protocol. A frequently changing customer mailing list can be accessed just as easily by a desktop sales management application as by a mail server that does the company's automated mailings; it can also be accessed by an external Web server application from an organization that's purchased the right to use the list. The barriers to global access are removed as the adoption of the protocol becomes widespread - which is certainly the case with LDAP.

LDAP has the potential to do for directories what HTTP and HTML did for documents - and Netscape provides the tools that let you unlock that potential. As Network Computing magazine put it in its October 1996 issue:

[HTTP] sparked a networking revolution . . . Now [LDAP] is poised to go even further . . . its potential is enormous.
THE EVOLUTION OF LDAP

Historically, directory-type information was often stored in an application-specific private database, possibly shared across small workgroups through LAN file sharing using some kind of proprietary protocol. Or an application-specific networked directory would use a protocol that was proprietary to the application (for example, Lotus Notes or Microsoft Exchange) or to the operating system (as in the case of the Novell NDS Directory), restricting use of the directory to people using that application or operating system. The need for a standard, open protocol became evident, but the eventual ISO standard, X.500, was complex and cumbersome to implement, and it was not acceptable as an Internet solution.

Along came LDAP, the Internet directory protocol (based on a client-server model) that was defined by the Internet Engineering Task Force (IETF) and initially developed at the University of Michigan at Ann Arbor. At first LDAP was just a simplified ("lightweight") front end to X.500, and even then it spurred a lot of development. It soon evolved into a stand-alone protocol and sparked even more interest. LDAP is not only a simpler protocol to implement than X.500 (especially in clients) but, since it's under IETF change control, it will naturally evolve to meet Internet requirements.

The IETF is expected to finalize LDAP version 3 as a proposed Internet standard by the end of 1997, and Netscape is already previewing version 3.0 of the Netscape Directory Server, the first commercial server software product based on the latest draft of this new standard.

LDAP is one of the very few Internet protocols that has become associated with a well-documented, well-known, and easy-to-use API. The LDAP API has been widely adopted; LDAP products and services are currently offered by more than 40 vendors, including Netscape, Novell, Oracle, Microsoft, and IBM.

WHAT'S WHAT: THE BASICS

Before going any further, let's take a closer look at some of the basic terms and tools having to do with directories and LDAP.

An LDAP directory client (or LDAP client for short) accesses a directory by interacting with an LDAP server through the LDAP API, a set of functions (or classes) that request the server to perform operations defined by the LDAP protocol. For example, the server responds to a search request by searching the directory and returning a list of the matching entries. Netscape Communicator is an example of an LDAP client; Communicator's address book feature enables a user to look up a person's e-mail address in various directories located on LDAP servers - not only the user's personal address book but also a corporate-wide directory or an Internet-wide directory such as Four11.

The Netscape Directory Server software package contains all the components necessary for building an LDAP directory service, including the LDAP server, an HTML-based client interface, and the Netscape Directory Client Software Developer's Kit (SDK) for creating custom LDAP clients. The Netscape Directory Server also includes the ability to replicate directory data, control access to the directory, and manage the types of information stored in the directory (more on these features later).

The Netscape Directory Client SDK, the latest version of which can be downloaded from the DevEdge Web site, consists of client-side software for accessing LDAP directory servers through the LDAP API. You can use this SDK to build an LDAP client or to make your existing application "directory-enabled" (sometimes called "LDAP-enabled"). Figure 1 illustrates the client-server relationship between a directory-enabled application and an LDAP server.

Figure 1. The LDAP client-server relationship

The Netscape Directory Client SDK provides two different kits; which one you'll use depends on whether you program in C or Java.

  • The LDAP C SDK is a set of C-based LDAP API libraries as well as command-line utilities for some directory operations. The command-line utilities are convenient for testing and for use with scripting languages such as Perl. (At one time the Netscape Directory SDK included only the LDAP C SDK; it has since been expanded to include the Java-based interface and has been renamed the Netscape Directory Client SDK.)
  • The LDAP Java SDK consists of the LDAP Java Classes, a library implemented entirely in Java that supports the functionality of the LDAP API through an object-oriented interface. This interface is consistent with data access objects in JavaSoft's Java Development Kit (JDK).
The LDAP Java Classes are included as part of Netscape Communicator 4.0 and can be used to incorporate LDAP access into an applet in a Web page. Furthermore, LiveConnect makes the LDAP Java Classes available to JavaScript. The LDAP Java SDK also supports using JavaBeans components to provide LDAP access. (We'll cover that subject in a future View Source article.)

ABOUT LDAP DIRECTORIES

Entries in an LDAP directory contain information about some object, such as a person. The entries are usually organized into a hierarchical tree. Each entry in the hierarchy is a collection of attributes; which attributes depends on the type of entry. Each attribute has a type plus one or more values. For example, an entry for a person can have attributes for the person's name, phone number, e-mail address, and so on.

The types of information that can be stored in a directory are defined by a schema in the directory server. The default schema describes people and groups in an organization. You can extend the schema by adding your own attributes or even your own entry types. You could, for instance, expand the standard entry for a user to include a driver's license number or create a new entry type that describes printers on a network.

THE CLIENT-SERVER INTERACTION

Here we'll look at the client-server interaction between a directory-enabled application and an LDAP server. We'll assume an application written in C, although of course similar functionality is provided through both the LDAP C and the LDAP Java SDKs.

The client connects to the server using a function in the LDAP C SDK. Simultaneously, or as a second step, the client can authenticate itself to the server. It does this by passing the server the user's name and password or other credentials - for example, an X.509 certificate - depending on the authentication mechanism chosen. An authenticated client may be able to access more information than one that isn't authenticated. A secure connection with encrypted data transmission is also available, through the Secure Sockets Layer (SSL).

Once connected and authenticated, the client can access the directory through functions in the LDAP API that perform the following operations, among others:

  • Find directory entries based not only on a search filter but also on the starting point and scope of the search, the specific attributes to return, and size and time limits
  • Add and delete entries
  • Modify and rename entries
These operations can be performed synchronously or asynchronously. When finished, the client calls a function to close its connection to the server.

It's as simple as that. But perhaps as you consider whether to directory-enable your application, you're concerned about the lack of control inherent in relying on a centrally located directory rather than a local file. If so, note that LDAP servers offer the feature of replication, which essentially keeps around multiple copies of a directory. Replication serves as a failsafe mechanism as well as a means of placing copies local to the user community, thereby reducing wide-area network bandwith requirements. In addition, your application can cache information read from a directory; that way, if the directory server is ever down or if your application is disconnected from the network, the application can still run (although perhaps with out-of-date directory information).

AN EXAMPLE OF DIRECTORY-ENABLING

As a simple example, suppose a Web-based purchase request application presents a form to the user to fill out. The user is prompted to enter an employee number, department, and phone number, as well as a manager's e-mail address for approval. Directory-enabling the application makes it possible for the form to be automatically filled out with the data and transmitted to the user's manager, saving time and money and avoiding typing errors that might cause the request to be misrouted or rejected.

Directory-enabling is as simple as embedding in the Web page a little bit of JavaScript that gets executed when the form is posted. A connection is made to the directory server, and the directory is searched to find the user's manager. The user's employee number, department, and phone number are extracted from the user's directory entry, the manager's e-mail address is extracted from the manager's entry, and an e-mail message containing the request is sent to the manager.

Once the manager approves the request, another bit of JavaScript can be executed to search the directory for the request's proper next destination, perhaps the purchase agent responsible for dealing with the vendor in question. Again, this can be accomplished via a simple directory search operation.

So you can see that without much work, an application can gain quite a lot of power from becoming directory-enabled. A future View Source article will take a closer look at this process, complete with code.

GOING FORWARD

We hope this article has inspired you to look further into taking advantage of directories and LDAP in your development efforts. Keep in mind these benefits:

  • Universal access. LDAP is the Internet directory standard, widely adopted and implemented by vendors everywhere.
  • Simplicity. Although it provides a wealth of features, LDAP is a relatively simple protocol with a straightforward API.
  • Extensibility. You can easily, dynamically extend beyond the standard schema, tailoring the LDAP directory to suit the needs of your application.
  • Access control and security. LDAP connections can be authenticated (requiring a password or other credentials) and secured through SSL.
  • Multiplatform development. C, Java, and JavaScript APIs are available, making LDAP directory services accessible from virtually any language, platform, or development environment you choose.
To get started, you'll want to download the Netscape Directory Server version 3.0 and the Netscape Directory Client SDK.

LDAP is becoming as ubiquitous for directory information as HTTP is for document transport over the Web. No doubt you'll want to join the growing world of developers and users who have discovered the power that directories and LDAP can provide.

Many thanks to Brian Byun, Tim Howes, Steve Sarette, Rob Weltman, and Doug Yoshinaga of Netscape and to Rich Kadel of DTAI Incorporated for their assistance in preparing this article.