IBM HTTP Server supports the use of Lightweight Directory Access Protocol (LDAP), a protocol that provides access to the X.500 directory over a TCP or SSL connection. LDAP lets you store information in a directory service and query it in a database fashion. When you use X.500 directories and LDAP, any LDAP-enabled application can store information once, such as user authentication information, and other applications using the LDAP server will recognize it.
LDAP reduces required system resources by including only a functional subset of the original X.500 directory access protocol (DAP).
IBM HTTP Server LDAP support is extremely scalable. You have a choice of LDAP configurations including:
This book assumes you have an existing X.500 directory service available, for example the IBM SecureWay X.500 directory.
X.500 is a directory service with components that provide more efficient retrieval. LDAP uses two of these components: the information model, which determines the form and character, and the namespace, which allows information to be indexed and referenced.
The X.500 directory structure differs from others in the way the information is stored and retrieved. Information is associated with attributes. A query based on attributes is generated and sent to the LDAP server, and the server returns the respective values. LDAP uses a simple, string-based approach for representing directory entries.
An X.500 directory consists of entries, which are typed depending on the ObjectClass attribute. Each entry is composed of attributes. The ObjectClass attribute identifies the type of entry (for example, person or organization), which determines which attributes are required and which are optional.
Entries, which are arranged in a tree structure, may be divided among servers in geographical and organizational distribution. They are named according to their position within the distribution hierarchy by a distinguished name (DN).
Accessing an X.500 directory requires a certain protocol, for example Directory Access Protocol (DAP). However, DAP requires large amounts of system resources and support mechanisms to handle the complexity of the protocol. To allow desktop workstations to access the X.500, LDAP was introduced.
LDAP is client/server based and some of the heavy resources required by DAP clients are handled by the LDAP server. An LDAP server can only return results or errors to the client, requiring little from the client. If an X.500 server is unable to answer a client request, it must chain the request to another X.500 server. The server must complete the request or return an error to the LDAP server, which in turn passes the information to the client. LDAP (Lightweight Directory Access Protocol) is an information directory where users and groups can be defined only once and shared across multiple machines as well as across multiple applications. The IBM HTTP Server LDAP plugin allows authentication and authorization (which is required when accessing a protected resource) to be performed by the directory, thereby greatly decreasing the administrative overhead for maintaining user and group information locally for each webserver.
LDAP accesses the X.500 directory through the use of human readable strings. When these query strings are passed to the LDAP server, the server returns the distinguished name of the entry.
LDAP entries are typed, or classified, by an ObjectClass attribute to simplify searches. For example, you could search an LDAP directory whose objectclass=acl to locate all entries that are access control lists.
A search filter for an LDAP entry has the following structure:
For more information on LDAP search filters, see RFC 1960.
Joe Smith
Joe Schmoe Adam Fosset any name other than Jane Doe
Peter Johnson Davey Johnson
University of North Carolina Chapel Hill University of South Carolina
Note: | LDAP can return more than one entry. However, the Web server will not authenticate when multiple entries are returned. If the University of North Carolina and the University of South Carolina were included in the directory queried by this example, both would be returned, and the authentication would fail. The search filter must be altered. |
Enter the authentication realm name for the directory in the Authentication realm name field.
To define by group:
LDAPRequire group "group_name"
Example: LDAPRequire group "Administrative Users"
To define by filter:
LDAPRequire filter "ldap_search_filter"
Example: LDAPRequire filter "(&(objectclass=person)(cn=*)(ou=IHS)(o=IBM))"
Note: LDAPRequire will only work if it is manually inserted into httpd.conf.