Apache authentication module

by Jon Meek
<meekj@pt.cyanamid.com>

Jon Meek is senior group leader of systems, networks, and telecommunications at the American Cyanamid Agricul-tural Products Research Division of the American Home Products Corp. His research interests include scientific applications of Web technology, data inte-grity, and network ecology.

After more than four years of widespread Web-based application development, the advantages of the technology are well known. Installation of a Web browser can provide an immediate and fairly uniform interface to a wide range of server-based applications and documents. The result is that anyone with a Web browser and access to Web servers can obtain business and scientific data from databases, documents, chemical instrumentation, network hardware, vending machines, or anything else that can communicate with a Web server.

In the early days, demonstrations showed how simply these data could be viewed with no special software or training. The question often asked, however, was, "If it is so easy to get this information, how are we protecting it from access by unauthorized users?" Another problem is user authentication for data input applications, a common requirement in the pharmaceutical and other regulated industries.

Standard Web authentication mechanisms were not acceptable for several reasons. They required "yet another password" and administrative overhead to manage usernames and passwords. From a security standpoint, the more serious problem is that standard Web browsers retain username/password combinations and transparently supply them to the server whenever needed. Anyone walking up to the browser session could assume the identity of the authenticated user and have access to private data.

Several years ago my first attempt to solve these problems consisted of authentication code built directly into specific CGI applications. The authentication methods were either the UNIX password or a SecurID (Security Dynamics, Bedford, MA) passcode. Although this solved a number of immediate problems, the limitations were significant. Users had to supply a password every time it was required, and accounts local to the Web server were required. For a global corporation with many divisions, this presents a significant administrative problem.

The AuthMPTO System

These problems were addressed by developing the Multi-Password/Time-Out Authentication system. The benefits of the system include elimination of separate Web password administration, a time-out mechanism, and a cookie containing the user's name, authentication method, and time of authentication.

The MPTO system consists of an Apache Web server (<www.apache.org>) module that runs under mod_perl (Perl embedded in the Web server software), a support module, and several database files. As implemented at our site, five different authentication mechanisms are available: (1) UNIX passwords for two NIS domains, (2) NT domain passwords for two domains, (3) VAX/VMS passwords, (4) SecurID, and (5) standard Web authentication. Users at sites in the US and Europe are currently supported by one or more of these authentication methods. To support additional sites without resorting to "standard Web passwords," Novell LAN password authentication will be added to the authentication mechanisms.

How It Works

The server administrator configures Apache to require authentication for a particular directory tree in a manner very similar to the standard method, except that mod_perl's PerlSetVar is used in the access.conf file to set a number of parameters. When a user attempts to access documents or applications within a protected directory, an http redirect is used to present the login form. The user selects the authentication method he or she wishes to use, then enters the username and password. When the form is submitted, the username and password are checked against the selected authentication mechanism. If the check is successful, a cookie string containing the time of authentication, username, authentication method, and client IP address is generated. A copy of this cookie is stored as a key in a dbm file on the Web server for future reference, and a "successful login" page is sent to the user's browser along with the cookie string. A URL labelled "Continue" at the bottom of the page will take the user to the originally requested page.

Each time the user attempts to access a secure page, the AuthMPTO cookie string is returned to the server and verified against the dbm file. Verification includes time and client IP address (to prevent spoofing). Our default setup allows access to secure items for up to 15 minutes following the most recent access of a secure item. When 60 minutes from the original authentication time have elapsed, the user is required to reauthenticate. This 15/60 minute time-out provides reasonable protection if the user walks away from an authenticated Web browser. The most recent access of secure items is tracked using the data portion of the dbm record.

Group Authorization

AuthMPTO provides a group authorization method. A single dbm file on the Web server uses keys of the form "username@auth_method" with a list of the groups the user belongs to as the data. If users attempt to access an item restricted to groups they do not belong to, access is refused, and a diagnostic page listing the group(s) allowed to access the item is displayed.

Several methods of automatically administering the group database are currently being considered. One is to use department codes from existing company databases along with supplemental files because department codes are unlikely to describe all possible combinations of group membership.

Authentication Methods

NIS authentication makes use of the Perl Net::NIS module by Rik Harris to retrieve the encrypted password that is checked using crypt by the standard Perl method. VAX/VMS authentication uses the Comm.pl Perl library written by Eric Arnold and does an "expect-like" conversation to actually log into a VMS system as a password check.

An early test version of NT domain authentication used smbclient (by Andrew Tridgell and the Samba Team) to do a test connection to an NT fileserver. That method suffered from a number of problems including putting the password on the command line, and required special care if guest logins were allowed on the fileserver. The current version uses a small stand-alone program written in C that uses smblib by Richard Sharpe. This program requires the following on standard input: a list of NT domain controllers, username, and password. The program returns the shell standard 0 for success, 1 for failure.

Use of Authorization Cookies

In addition to providing the basic authorization token, the MPTO cookie data can be easily used by Web applications. An example is to use the username, and possibly the authentication method, to fill in noneditable fields of a data entry form as a type of electronic signature. In this example, the final entry of data into the database would use the cookie data to obtain a fresh copy of the username to prevent HTML form spoofing.

Configuration and Security Issues

AuthMPTO is designed for use in a controlled corporate environment. The Apache Web server is configured to run as the user "www," which owns the cookie dbm file. Care must be taken to restrict access to the Web servers in general, and especially access to the cgi-bin directories. A rogue cgi-bin script could place cookie records in the dbm file because, by default, all cgi programs run as the user www.

After further testing, the availability of AuthMPTO will be announced through the Apache Module Registry at <www.apache.org>.