7.7 Lightweight directory access protocol
|
7.7 Lightweight directory access protocol
The Lightweight Directory Access Protocol, or LDAP, is a directory protocol.[4] LDAP defines a simple mechanism for directory clients to query and manage a database of hierarchical entries. Overall, LDAP is a simplification of the X.500 directory access protocol that we discussed in the first part of this chapter. If you delve into the LDAP protocol, you will see that it is a subset of the X.500 access protocol. As a result, LDAP can access X.500 directories, and LDAP and X.500 servers can interoperate within the same environment. LDAP runs directly over TCP, eliminating the need for the complicated OSI (Open Systems Interconnection) stack.
The LDAP directory service model is based on specific and unique entries. An entry is a single collection of attributes with a single key ("key," in this case, is a parameter that can be used to look up something, and not a key for encryption). Each entry will have a name. As you may recall, we have discussed DNs, or distinguished names. The DN is used as a unique value that represents each collection, or entry. Much like the X.500, each of the entry's attributes has a type and one or more values. Again, like the X.500 example that we have shown before, the LDAP directory entries are arranged in a hierarchical, treelike structure. This structure can reflect political, geographic, or organizational boundaries.
The LDAP directory service is based on a client-server model. An LDAP server will offer the directory data via TCP/IP port 389 and SSL encrypted port 636. Clients will access the LDAP server via a set of queries. The results of the queries can be used in messaging, applications, and authentication. One feature that is built into the protocol is that of a referral. If, in the process of a query, an answer is not available on the local server, then, if configured to do so, the LDAP server will attempt to connect to another server. If that server can service the request, then the result of the query will be returned to the client. One example of this could be name resolution; you may have a person's name but not his or her RFC 821 Internet address (this is an address like Bubba@myemailserver.com).
In Figure 7.7, the client sends a request for "Bubba Duck"; the first server performs a lookup and does not find the entry in its local database. The server then sends a referral to the X.500 server and the entry is found. A lookup is performed for "Bubba Duck," the RFC 821 address is returned to the LDAP server, and then sent from the LDAP server back to the client.
Figure 7.7
LDAP servers are also capable of managing transaction logs, which is a process for chronicling adds and changes, and for deleting entries. Using this system, an LDAP server propagates these changes to other LDAP servers. This way, you can have one LDAP server send the same data to several other LDAP servers.
There is also a method to access LDAP information via a URL.[5] A predefined format is listed in RFC 1959.[6] This format is described as an LDAP search operation to retrieve information from an LDAP directory.
Following is an extract of the RFC 1959 that describes the URL syntax:
2. URL Definition
An LDAP URL begins with the protocol prefix "ldap" and is defined by the following grammar.
<ldapurl> ::= "ldap://" [<hostport>] "/" <dn> ["/" <attributes> ["?" <scope> "?" <filter>] <hostport> ::= <hostname> [":" <portnumber> <dn> ::= a string as defined in RFC 148 <attributes> ::= NULL | <attributelist> <attributelist> ::= <attributetype> |<attributetype> ["," <attributelist> <attributetype> ""= a string as defined in RFC 1777 <scope> ::= "base" | "one" | "sub <filter> ::= a string as defined in RFC 155
Example:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c US??sub?(cn=smith
LDAP can be used to store X.509 certificates for authentication. The certificates are placed into the directory and then accessed via a web server. In Figure 7.8, a user attempts to access a secure page. The web server returns a status code of 401. Then the users send the query back with their credentials (the user logs in). The web server looks to see if the information is local; if the information is not local, it performs a bind operation on the LDAP server and connects to it. Then the web server sends over a query checking for validity of the credentials. If the credentials are valid, a DN is returned back to the web server. The web server then checks to see if that DN has access to the resource being requested; if the request is valid, the page is returned to the browser.
Figure 7.8
