Web Server Authentication | The ABCs of LDAP: How to Install, Run, and Administer LDAP Services

< Day Day Up >

As mentioned in the introduction to this chapter, the need to streamline authentication is often the first consideration in using LDAP. Over time, the proliferation of userIDs and passwords can become quite high in many enterprises. Indeed, it is not unusual for a single user to have ten UserID/password combinations and more. In international enterprises, the situation can be even worse because each country may have its own database of users.

Web servers did not simplify this situation. They introduced a new combination of UserID and password and, frequently, a different combination for every type of application.

The ability of LDAP to permit authentication over TCP/IP made it an ideal partner for Web servers. A Web server implies the presence of a network, so why not use this network for authentication also? This method allows the use of one authentication method not only inside one Web server, but across all Web servers in the enterprise.

Because it is possible to synchronize NT primary domain controller (PDC) accounts with a simple Perl program with LDAP, you can use LDAP accounts for UNIX, Samba, and, finally, for Web applications. The usage in the Web server allows you to assign each user a single UserID/password combination that applies throughout the enterprise's intranet. This is obviously an ideal situation. But any strategy that can reduce the number of different accounts would be a welcome event.

This chapter is called "LDAP and Web Services" because most Web servers allow built-in LDAP authentication. The most popular Web server, the Apache Web server, has several different modules to allow built-in authentication against a directory server. Apache integrates this functionality in the form of a module.

The Web server controls the access to Web pages or applications. It achieves three objectives:

It executes the authentication of the user, i.e., it verifies that the user is who he or she claims to be.
It executes the authorization of the user, i.e., it controls whether the authenticated user is allowed to view the page or execute the application requested.
It delivers the userID of the authenticated/authorized user in the form of an environment variable for later use.

There are several modules available for the Apache Web server. In this chapter, we will use the auth_ldap module from Dave Carrigan, available from: http://www.rudedog.org. I use this module in my Web server implementation. The module is well documented, easy to install, and straightforward to use. This is not intended to imply that other solutions are inferior. Check the Internet to see what is out there. By the time you read this book, the software landscape may be quite different. If you are using the Apache Web server, have a look at its module registry, http://modules.apache.org. The module registry is one of the subprojects maintained by the Apache group (http://www.apache.org).

Example: The auth_ldap Module for Apache

To illustrate how the authentication in the Web server works, let us have a look at the auth_ldap module from Dave Carrigan and the Apache Web server. The installation of auth_ldap is similar to the installation of other modules available from the site of the Apache Web server. If you have problems, you can also count on the support of a user group working heavily with this module.

As mentioned previously, the Web server executes two steps before it allows the user to access the requested information:

The authentication phase
The authorization phase

The Authentication Phase

Before the LDAP module can authenticate against the directory, you first have to instruct the Web server to ask the user for a userID and password. Once these are obtained, the Web server proceeds, constructing the LDAP URL it should use for authentication. The LDAP URL is constructed following the specification described in RFC 225. Recall that the syntax of the URL is: ldap://host:port/basedn?attribute?scope?filter. Based on this knowledge, the Web server constructs the following filter:

 (&(filter)(attribute=username))

If the search succeeds and returns only one entry, the Web server tries to authenticate using the distinguished name retrieved from the search and the password supplied by the user.

The Authorization Phase

Once the user is authenticated, the Web server proceeds to see if the user is authorized to access the requested information. Based on its configuration file, the Web server controls which of the following directives return true. Valid directives are:

require valid-user: Any authenticated user can access
require user: Only the users with the specified userID have access
require dn: Only users with the specified distinguished name have access
require group: Only users of this group (groupOfUniqueNames) have access

For example:

 AuthLDAPURL ldap://LdapAbc.org:389/ o=LdapAbc.org?uid require valid-user

grants access, allowing every valid user in the directory based on the userID (uid). Similarly:

 AuthLDAPURL ldap://LdapAbc.org:389/ o=LdapAbc.org?cn require valid-user

grants access, but in this case the authentication is made using the "cn" attribute. This is not a recommended approach. You should use a unique attribute for authentication. The following code:

 AuthLDAPURL ldap://LdapAbc.org:389/o=LdapAbd?uid require group cn = admin, o = LdapAbc.org

allows access only to persons in the admin group. Finally:

 AuthLDAPURL ldap://LdapAbc.org/o=LdapAbc.org?uid?? (|(mail=*)(uid=admin)) require valid-user

allows persons who have an e-mail account and who are part of the administration team.

LDAP Authentication Using CGI Scripts

The authentication in CGI scripts works like the authentication in scripts or programs. As explained in the previous section, the only difference between a program and a CGI script executed on behalf of a Web server is that the HTTP protocol does not support sessions. The concept of a session has to be simulated by the application. Most Web servers also offer session support. There are two possible strategies for maintaining a session:

Cookies
Query parameters passed from one page to the other

As we have seen in Chapter 4, there are a great many programming languages for which LDAP libraries or classes are available. It is very likely that you will be able to LDAP-enable your Web application with one of these LDAP libraries.

LDAP Authentication Using the PHP Preprocessor

PHP is a preprocessor that can be compiled into a Web server, for example the Apache Web server. For more details about the PHP preprocessor, see the "LDAP and PHP" section in Chapter 6. The software and documentation are available from the Web site of the PHP project: http://www.php.net.

The example cited in Chapter 6 shows you how authentication works. Exhibit 4 shows the PHP script again in a simplified form. The important lines are printed in bold. First, we try to get the user credentials in lines 8 and 9. Line 14 connects to the LDAP server, line 18 tries to bind with the user credentials. If the bind is successful, the page can be displayed. If there is no bind, an error page replaces the current one.

 <?php session_start();   // Configuration: $LDAP_Server = "LdapAbc.org" ; $LDAP_BaseDN = " ou=IT, o=LdapAbc.org" ; $Error_HTML = "/Error.html" ; // Grabbing Parameters from Script Environment:    $CallingScript = $HTTP_SERVER_VARS['PHP_SELF'];    $login = $HTTP_POST_VARS['login']    $password - $HTTP_POST_VARS['password'] ;    Location=sprintf("http://%s/%s",                      $HTTP_SERVER_VARS['HTTP_HOST'],                      dirname($HTTP_SERVER_VARS['PHP_SELF']) );    // Connect to the LDAP server:    $ds=ldap_connect($LDAP_Server);    // Construct the DN the User binds with    $udn="u,".$LDAP_BaseDN ;    // Bind to the directory:    $res=@ldap_bind($ds,$udn,$password);    if ( $res && (chop($login) ! = "" ) && (chop($password) !="" )  ) {    // Everything's ok, so we just do nothing,    // that means the following HTML becomes displayed    } else {      $Location = $Location.$Error_HTML ;      echo "window.location.replace(\"$Location\") ; "    } ?>

Exhibit 4: php Script for LDAP Authentication

The PHP script in Exhibit 4 executes every time it encounters the bind action. Furthermore, it requires the userID and password to be contained as environment variables. The user credentials are required because the HTTP protocol is a connectionless protocol, and as such, it does not maintain state information between the individual requests.

If you wish to protect an entire subsite, a better choice than a PHP script would be to use one of the built-in LDAP modules of the Web server you are using. However, it may be that you have chosen to use PHP for authentication, and if so, you have to include an authentication script in every page of the site you wish to protect. PHP lets you include a centrally maintained PHP script via the "include" clause. To avoid authentication each time an HTML page is displayed, you could use the session-tracking capabilities of the PHP language. Chapter 6 has a complete working example that includes a configurable timeout interval after which the session expires and the user has to log in again. For more information about session variables and the use of PHP inside HTML, have a look at the PHP project page.

< Day Day Up >