7.5 Kerberos and Web-Based Applications

Web-based authentication is an important issue for many organizations that want to extend their single-sign-on infrastructure to the web, for both internal intranet applications as well as external internet applications. Authentication can either be handled by the web application itself, by providing the user an HTML page with form entries for a username and password, or by the web server, through the HTTP protocol. This section discusses an Apache module that provides administrators the ability to verify Kerberos passwords through an Apache module.

The web server and browser perform HTTP authentication, with the resulting verified username returned by the web server to the web application. When an end user requests a resource on a web server for which the server is configured to require authentication, the web server returns an error 401 (Not Authorized) to the client. This error message includes an HTTP header, WWW-Authenticate, that provides the client a challenge. Based on the response that the client provides the server, the server may choose to provide the client access to the requested resource, or continue to return 401 errors to the client if the response returned by the client is unsatisfactory. With this generic method, any challenge-response security protocol can be used for HTTP authentication.

The HTTP specification defines two authentication methods based on the above challenge-response architecture: Basic and Digest authentication (defined in RFC 2617). The most widely implemented of the two is the Basic method, in which the challenge consists simply of a realm name (not to be confused with a Kerberos realm) returned by the server to the client defining the resource for which the client is requesting access. Upon receipt of a 401 error with a request for Basic authentication, the browser displays a dialog box with prompts for username and password, and a label containing the name of the realm to which the user is requested to authenticate herself. The username and password is sent back to the server encoded in Base-64 (essentially in the clear, as no encryption is performed, Base-64 is just a transformation to eliminate ambiguity when decoding the response). Digest authentication uses a true challenge-response architecture but is not widely implemented since it requires the server to have the plain text of all users' passwords in order to verify authentication responses.

In addition to Basic and Digest, Microsoft IIS and Internet Explorer also support NTLM authentication, which uses the challenge-response Microsoft NTLM protocol to perform authentication between Microsoft-based browsers and servers. With the introduction of Windows 2000, Microsoft added Kerberos authentication to both IIS and Internet Explorer. Microsoft chose to implement Kerberos authentication through the use of a new HTTP authentication mechanism, Negotiate, layered with the Simple and Protected GSSAPI Protection Mechanism (SPNEGO, defined in RFC 2478). Through this mechanism, Internet Explorer can use native Kerberos authentication to access protected resources on an IIS server and provide single-sign-on for these resources. More information on the Microsoft implementation of Negotiate and SPNEGO as a web authentication method can be found at http://msdn.microsoft.com/library/en-us/dnsecure/html/http-sso-1.asp.

An implementation of SPNEGO and the Negotiate HTTP mechanism that interoperates with Microsoft Internet Explorer is under development, and the code is availabe at http://modgssapache.sourceforge.net. As this code is still under development, installation and configuration is still rough and subject to change. Installation instructions for the current version are available at the above web site, and I'll document my own adventures with it on the O'Reilly Network.

However, no web browsers other than Internet Explorer currently support native Kerberos authentication through the Negotiate mechanism. Therefore, the only true cross-platform solution to Kerberos on the Web at the moment is by passing Kerberos usernames and passwords over the network through Basic authentication, preferably through SSL in order to avoid passing the plain text passwords in the clear. The mod_auth_kerb Apache module, available at http://modauthkerb.sourceforge.net, provides this capability to Apache. This is the method we will discuss to provide Kerberos authentication to web resources.

There are several problems to this approach from a security standpoint. First is the lack of mutual authentication: while the web server may be able to accurately determine the identity of the requesting user, the user has no way of knowing that he is talking to the legitimate web server. While using SSL mitigates this somewhat, there is still the possibility an attacker could establish a site with a valid SSL certificate and similar content. And since Basic authentication only specifies a simple text "realm name" (not to be confused with Kerberos realm) to be displayed during authentication, this name can easily be spoofed by an attacker intending to acquire passwords from users.

The second issue is passing the plaintext Kerberos password over the network. Again, using SSL mostly solves this problem, and it is highly recommended that web servers using mod_auth_kerb also use SSL to protect users' passwords in transit. Both of these issues would be solved with native GSSAPI support on browsers and servers, and it would also provide the benefit of single-sign-on, but at the moment there is no standard for GSSAPI support other than the Microsoft implementation.

7.5.1 Building the mod_auth_kerb Apache Module

After downloading the mod_auth_kerb C source file, it can be built as a dynamic shared object (dso) that can be loaded into Apache during runtime. The distribution consists solely of a single C source file, mod_auth_kerb.c. There is no configure script, so the Apache apxs program must be run manually to compile the source file with the appropriate options to create a valid Apache module. In addition, the Kerberos libraries and include directories have to be specified.

Before beginning, ensure that your Apache has support for loadable modules compiled in. Find the httpd binary, and use the -l option to list the modules compiled into the Apache binary. As long as mod_so is listed, then your Apache has support for dynamically loadable modules:

% ./httpd -l
Compiled-in modules:
  http_core.c
  mod_so.c

Table 7-1 shows the compile-time options available when building mod_auth_kerb.

Table 7-1. mod_auth_kerb compile-time options

Option	Description
KRB5	Needs to be defined for Kerberos 5 support.
KRB_DEF_REALM	Defines the default realm that is used when authenticating users. This realm is appended to usernames sent by browsers to form a complete principal name. Note that the realm must be contained in quotes, and double-escaped as it is passed through several scripts.
APXS2	Define this if you intend to run mod_auth_kerb with an Apache 2.x web server. Otherwise, a module for Apache 1.3.x is built.
KRB5_SAVE_CREDENTIALS	Forces mod_auth_kerb to keep the user's TGT after authentication—useful for CGI scripts that may contact further Kerberos servers with the end user's credentials. When using this option, the credential cache is stored in /tmp/krb5cc_username, where username is the username portion of the authenticated principal.
KRB5_VERIFY_TICKET	Requires the module to retrieve a service ticket for the www/hostname@REALM principal before the user is successfully authenticated. This option is highly recommended to prevent man-in-the-middle spoofing attacks as explained in Chapter 6.
KRB_V5_KEYTAB	This option defines the path to the Kerberos 5 keytab for the www/hostname principal, which is used if KRB5_VERIFY_TICKET is defined to ensure that the KDC reply is genuine and not an attacker spoofing the KDC. Similar to the KRB_DEF_REALM option, this option also needs to be enclosed in quotes and appropriately shell-escaped. Since Apache usually does not (and should not) run as root, this keytab should be readable only by the username that Apache runs as.

In addition to these options, the paths to the include and library paths of your Kerberos implementation must also be included on the compile line. Modern Kerberos distributions include a script, krb5-config, that provides this information. Assuming that the module is being built for an Apache 1.3.x web server, a compile line looks like this:

% apxs -c -DKRB5 -DKRB5_VERIFY_TICKET -DKRB_V5_KEYTAB=\\\"/etc/apache.keytab\\\" 
-DKRB_DEF_REALM=\\\"WEDGIE.ORG\\\" `/usr/local/bin/krb5-config --cflags` 
`/usr/local/bin/krb5-config --libs` mod_auth_kerb.c

Compiling mod_auth_kerb for Apache 2 is similar; replace apxs with apxs2 and add the -DAPXS2 define to the command line. Hopefully, the build completes successfully and a mod_auth_kerb.so file is created in the current directory. Copy this module into your Apache installation's module directory.

7.5.2 Configuring mod_auth_kerb

Once the module has been built and placed in the Apache module directory, then it can be added to the server's httpd.conf file. Add the following LoadModule line:

LoadModule kerb_auth_module     libexec/apache/mod_auth_kerb.so

Also add the following AddModule line to your httpd.conf file:

AddModule                 mod_auth_kerb.c

Once these lines are in place in the httpd.conf configuration file, then the Kerberos authentication module can be configured for use through htaccess files or directly inside of the Apache configuration file, like any other Apache authentication module. An htaccess file looks like the following:

AuthType KerberosV5
AuthName "Kerberos password"
KrbAuthRealm WEDGIE.ORG
require valid-user

This example prompts users to enter in credentials, asking for their "Kerberos password" as defined in the AuthName clause. Note that this will accept any valid credentials for any principal in the WEDGIE.ORG Kerberos realm. If further access control is desired, the standard Apache user list and group functionality can be used to limit authorization to a subset of principal names. An up-to-date list of the configuration directives that can be placed in the htaccess file can be found at the mod_auth_kerb site.