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.
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:
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.
The Netscape Directory Client SDK provides two different kits; which one you'll use depends on whether you program in C or Java.
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:
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.
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.
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:
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.