Mac OS X and the Login Window

[ Team LiB ] [ Team LiB ]

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.comlibraryen-usdnsecurehtmlhttp-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 Ill document my own adventures with it on the OReilly Network. [ Team LiB ] [ Team LiB ]