Understanding and Deploying LDAP Directory Services > 3. An Introduction to LDAP > What Is LDAP? |
What Is LDAP?At its core , LDAP is a standard, extensible directory access protocol ”a common language that LDAP clients and servers use to communicate with each other. Standardization of the protocol has the benefit that client and server software from different vendors can interoperate . When you buy an LDAP-enabled program, you can expect that it will work with any standards- compatible LDAP server. This has many advantages, but we'll discuss those later in this chapter. LDAP is a "lightweight" protocol, which means that it is efficient, straight- forward, and easy to implement, while still being highly functional. Contrast this with a "heavyweight" protocol, such as the X.500 Directory Access Protocol (DAP). X.500 DAP uses complex encoding methods and requires use of the OSI network protocol stack ”a networking system that has failed to gain wide acceptance. LDAP, on the other hand, uses a simplified set of encoding methods and runs directly on top of TCP/IP. Every major desktop and server computing platform currently available (Microsoft Windows, DOS, UNIX, and the Apple Macintosh) either ships with a TCP/IP implementation or can be easily equipped with one. OSI networking, on the other hand, is not universally available, and it is almost always an extra-cost option. LDAP, by virtue of its light weight, removes significant barriers to implementation and deployment. As mentioned in Chapter 2, there have been two major revisions of the LDAP protocol. The first widely available version was LDAP version 2, defined in RFCs 1777 and 1778. As of this writing, LDAP version 3 is a Proposed Internet Standard, defined in RFCs 2251 through 2256. Because it is so new, not all vendors completely support LDAPv3 yet. As we discuss LDAP in this chapter, we will focus our discussion on LDAPv3. However, we will point out new features found only in LDAPv3 so that you can understand the limitations you will encounter if you are using LDAPv2. In addition to its role as a network protocol, the LDAP standards also define four models that guide you in your use of the directory. These models promote interoperability between directory installations while still allowing you the flexibility to tailor the directory to your specific needs. The models borrow concepts from X.500, but they generally lack many of the restrictions that the X.500 models include. The four LDAP models are as follows :
In addition to guiding you in the use of your directory, the LDAP models guide directory developers when designing and implementing LDAP server and client software. The LDAP models are discussed in detail later in the chapter. There are several LDAP APIs, the oldest of which is for the C programming language. The C API is supported by several freely available software development kits (SDKs), including one available in binary and source code format from Netscape Communications Corporation. In addition to the C API, Netscape's freely available Java SDK (also available in binary and source code formats) supports all LDAPv3 features. Netscape also provides PerLDAP, a toolkit for the Perl language that allows you to access LDAP directories. SunSoft's JNDI is a proprietary, unified directory access API that supports access to multiple types of directory services (NIS+, LDAP, and others). Microsoft offers its own proprietary unified directory access API, known as Active Directory Services Interface (ADSI). These APIs and their various strengths are covered later in this chapter and in Chapter 20, "Developing New Applications." LDAP also defines the LDAP Data Interchange Format (LDIF), a common, text-based format for describing directory information. LDIF can describe a set of directory entries or a set of updates to be applied to a directory. Directory data can also be exported from one directory and into another using LDIF. Most of the commonly available command-line utilities also read and write LDIF. The LDIF format is discussed in more detail later in this chapter. What Can LDAP Do for You?If you are a system administrator, then LDAP
If you are a IT decision maker, then LDAP
If you are a software developer, then LDAP
For example, before the advent of LDAP, each of your applications probably had its own directory of user information. If you had a LAN-based email package, there was probably an interface you used to create and manage users and groups. If you had a LAN-based collaboration package from a different vendor, it most likely had its own directory and method of accessing that directory. And, often, if you used LAN-based file server software, it probably had its own distinct user directory. Some vendors offered packaged solutions, which made it possible to manage users and groups in one place ”as long as you used only their software suite. However, if you needed to mix and match software from multiple vendors, you probably ended up developing an elaborate procedure for ensuring that new employees were added to each package's proprietary directory. With LDAP comes the promise of eliminating this management nightmare. Instead of creating an account for each user in each system he or she needs to access, you will be able to simply create a single directory entry for the user ”and all directory-enabled applications will simply refer to the user's entry in the LDAP directory. When an employee is terminated , access to all systems can be revoked by removing the user's directory entry instead of hunting down all accounts granted to the person and disabling each one. Users benefit as well because they need to remember and manage only a single password instead of one for each system. In addition to consolidating the management of your users' access privileges, LDAP directories allow easier sharing of directory information with trading partners in an extranet environment. If you have established business relationships with other companies, you can use the directory to share common user information between your two organizations. This allows you to set up workflow processes that cross company boundaries, making both organizations more efficient. LDAP directories also can be used to build entirely new applications. An Internet service provider, for example, might create an LDAP directory that contains information about all its subscribers and the special add-on services it may have purchased. The directory can be consulted each time the user wants to access a given service. If the user has appropriate permissions, as registered in the directory, the application grants the user access; otherwise , access is denied . Management of all the value-added services is handled by updating the directory. Not all software vendors have made the transition to LDAP-based management, but LDAP has tremendous momentum in the software industry. Over time, more and more applications will be directory-enabled with the net benefit of reducing the total cost of ownership of your applications. How Does LDAP Work?In this section, we'll delve into the LDAP protocol in detail. We'll start with an overview of LDAP as a client/server protocol. We'll then discuss the individual LDAP protocol operations and show how clients can use them to perform useful tasks such as sending secure email. We'll also discuss LDAP extensibility, and we'll conclude by showing you how LDAP works "on the wire" by discussing the actual wire protocol. A client/server protocol is a protocol model in which a client program running on one computer constructs a request and sends it over the network to a computer (possibly the same computer) running a server program. The server program receives the request, takes some action, and returns a result to the client program. Examples of other client/server protocols are Hypertext Transfer Protocol (HTTP), which is typically used to serve Web pages; and Internet Message Access Protocol (IMAP) , a protocol used to access electronic mail messages. The basic idea behind a client/server protocol is that it allows work to be assigned to computers that are optimized for the task at hand. For example, a typical LDAP server computer will probably have a lot of RAM that it uses for caching the directory contents for fast performance. It will also probably have very fast disks and a fast processor, but it probably doesn't need a large-screen monitor and expensive graphics support. A client computer, on the other hand, might be on an employee's desk, probably optimized for the type of work that the employee does. Rather than putting a copy of the corporate directory on every employee's workstation, it's a better idea to maintain the directory centrally on a server (or replicated set of servers). The LDAP protocol is a message-oriented protocol. The client constructs an LDAP message containing a request and sends it to the server. The server processes the request and sends the result or results back to the client as a series of LDAP messages. For example, when an LDAP client searches the directory for a specific entry, it constructs an LDAP search request message and sends it to the server. The server retrieves the entry from its database and sends it to the client in an LDAP message. It also returns a result code to the client in a separate LDAP message. This interaction is shown in Figure 3.1. Figure 3.1 A client retrieves a single entry from the directory.If the client searches the directory and multiple matching entries are found, the entries are sent to the client in a series of LDAP messages, one for each entry. The results are terminated with a result message, which contains an overall result for the search operation, as shown in Figure 3.2. Figure 3.2 A client searches the directory, and multiple entries are returned.Because the LDAP protocol is message-based, it also allows the client to issue multiple requests at once. Suppose, for example, a client might issue two search requests simultaneously . In LDAP, the client would generate a unique message ID for each request; returned results for specific request would be tagged with its message ID, allowing the client to sort out multiple responses to different requests arriving out of order or at the same time. In Figure 3.3, the client has issued two search requests simultaneously. The server processes both operations and returns the results to the client. Figure 3.3 A client issues multiple LDAP search requests simultaneously.Notice that in Figure 3.3 the server sends the final result code of message ID 2 to the client before it sends the final result code from message ID 1. This is perfectly acceptable and happens quite frequently. These details are typically hidden from the programmer by an LDAP SDK. Programmers writing an LDAP application don't need to be concerned with sorting out these results; the SDKs take care of this automatically. Allowing multiple concurrent requests "in flight" allows LDAP to be more flexible and efficient than protocols that operate in a "lock-step" fashion (for example, HTTP). With a lock-step protocol, each client request must be answered by the server before another may be sent. For example, an HTTP client program ”such as a Web browser that wants to download multiple files concurrently ”must open one connection for each file. LDAP, on the other hand, can manage multiple operations on a single connection, reducing the maximum number of concurrent connections a server must be prepared to handle. The LDAP Protocol OperationsLDAP has nine basic protocol operations, which can be divided into three categories:
We will discuss each of the individual protocol operations when we describe the LDAP functional model later in this chapter. A typical complete LDAP client/server exchange might proceed as depicted in Figure 3.4. Figure 3.4 A typical LDAP exchange.In Figure 3.4, an LDAP client and server perform the following steps:
By combining a number of these simple LDAP operations, directory-enabled clients can perform complex tasks that are useful to their users. For example, as shown in Figure 3.5, an electronic mail client such as Netscape Communicator can look up mail recipients in a directory, helping a user address an email message. It can also use a digital certificate stored in the directory to digitally sign and encrypt an outgoing message. Behind the scenes, the user's email program performs a number of directory operations that allow the mail to be addressed, signed, and encrypted. But from the user's point of view, it is all taken care of automatically. Figure 3.5 A directory-enabled application performing a complex task.Although end-user applications can certainly be directory enabled, they are not the only kind of directory enabled applications. Server-based applications often benefit from being directory enabled, too. For example, the Netscape Messaging Server can use an LDAP directory when routing incoming electronic mail, as shown in Figure 3.6. Figure 3.6 A directory-enabled server application.These are just two examples of how directory-enabled applications can leverage the power of the directory to add functionality and ease of management. We will see more and more of this in the future. In addition to providing the nine basic protocol operations, LDAP version 3 is designed to be extensible via three methods:
How does an LDAP client know whether a particular LDAP extended operation, LDAP control, or SASL mechanism is supported by the server it is in contact with? LDAP version 3 servers are required to advertise the extended operations, controls, and SASL mechanisms they support in a special directory entry called the root DSE. The root DSE contains a number of attributes that describe the capabilities and configuration of the particular LDAP server. Standardization of LDAP Extensions How does an enhancement such as a new extended operation, LDAP control, or SASL authentication method become a standard? It goes through a standardization process in the Internet Engineering Task Force (IETF). First, the enhancement is described in a document called an Internet Draft. The draft is reviewed by participants in the IETF, changes and improvements are made, and revised drafts are submitted by the authors. Once there is consensus in the IETF that the enhancement is a good idea, and is soundly designed, the document becomes a Proposed Internet Standard. It then goes through more peer review, becomes a Draft Standard, and finally becomes a full Internet Standard. However, multiple interoperable implementations are required before a document makes it all the way through the standards process to prove that implementation is feasible . At all times during this process, the document is freely available on the Internet for anyone to download, read, comment on, and implement. The whole process is designed to encourage open development of standards and thorough peer review, without bogging it down with a complex standardization process. This approach has worked quite well historically; it's how the Internet was designed and built! The LDAP Protocol on the WireWhat information is actually transmitted back and forth between LDAP clients and servers? We won't go into a great deal of detail here because this book isn't about protocol design, but we do feel that there are a few things you might want to know about the LDAP wire protocol. LDAP uses a simplified version of the Basic Encoding Rules (BER). BER is a set of rules for encoding various data types, such as integers and strings, in a system-independent fashion. It also defines ways of combining these primitive data types into useful structures such as sets and sequences. The simplified BER that LDAP uses is often referred to as lightweight BER (LBER). LBER does away with many of the more esoteric data types that BER can represent, and instead it represents most items as simple strings. Because LDAP is not a simple text-based protocol like HTTP, you can't simply telnet to the LDAP port on your server and start typing commands. The LDAP protocol primitives are not simple strings, so it's difficult, if not impossible , to converse with an LDAP server by typing at it. If you are familiar with text-based Internet protocols such as POP, IMAP, and SMTP, this may seem like an unfortunate limitation. On the other hand, DNS, a very successful distributed system, uses a protocol that has nontextual protocol primitives. The presence of universal implementations of client libraries for both DNS and LDAP makes this limitation less problematic .
|
Index terms contained in this sectionabandon operationaccess user directory entries 2nd Active Directory Services Interface, see ADSI add operation administrators system LDAP benefits ADSI (Active Directory Services Interface) APIs ADSI (Active Directory Services Interface) JNDI APIs (application programming interface) application programming interfaces, see APIs applications building distinct directories proprietary directories server directory enabling user directory-enabling authentication operations Basic Encoding Rules, see BER benefits LDAP for IT decision makers for software developers for system administrators BER (Basic Encoding Rules) LDAP wire protocol 2nd bind operation building applications C API client/server protocols 2nd 3rd 4th clients requests multiple 2nd 3rd compare operation control operations controls protocol operations delete operation developers software LDAP benefits directories applications building user entries 2nd Draft Standards extension standards extended protocol operations extensions standardization standards Draft Standard full Internet Standard IETF Internet Drafts Proposed Internet Standard extranets resource sharing full Internet Standards extension standards functional model HTTP (Hypertext Transfer Protocol) Hypertext Transfer Protocol (HTTP) IETF extension standards IMAP (Internet Message Access Protocol information model Internet Drafts extension standards Internet Message Access Protocol (IMAP) interrogation operations JNDI API LBER(lightweight Basic Encoding Rules) 2nd LDAP APIs benefits for IT decision makers for software developers for system administrators clients multiple requests 2nd 3rd exchange example 2nd 3rd extensions standardization standards LDIF (LDAP Data Interchange Format) models platform support protocol operations 2nd revisions vendor support wire protocol LBER (lightweight Basic Encoding Rules) 2nd LDAPv3 LDIF (LDAP Data Interchange Format) manageDSAIT control message-oriented protocols messages search request models LDAP modify DN operation modify operation multiple client requests 2nd 3rd naming model networks extranets resource sharing operations LDAP 2nd protocol controls extended platforms LDAP support privileges user access directory entries 2nd Proposed Internet Standards extension standards proprietary directories integrating applications protocols client/server 2nd 3rd 4th HTTP (Hypertext Transfer Protocol) IMAP (Internet Message Access Protocol) message-oriented operations 2nd controls extended requests client multiple 2nd 3rd resourcrs sharing extranet environments revisions LDAP RFCs LDAP revisions search operation search request messages security LDAP model operations authentication TLS (transport layer security) servers applications directory-enabling sharing resources extranet environments software developers LDAP benefits standardization extensions standards extensions Draft Standard full Internet Standard IETF Internet Drafts Proposed Internet Standard StartTLS extended operation support vendor systems administrators LDAP benefits TLS (transport layer security) transport layer security (TLS) unbind operation update operations users applications directory-enabling directory entries 2nd vendors LDAP support wire protocol (LDAP) LBER (lightweight Basic Encoding Rules) 2nd |
2002, O'Reilly & Associates, Inc. |