Windows Authentication

Introduction

Many users are familiar with SSL encrypted web pages that ask them for their username and password to log into a web site. With SSL, web browsers use a gold lock as a visual cue to indicate to users that their username and password will be transmitted securely over the Internet. For example, this is what Wells Fargo Bank customers see in the lower right hand corner of the Internet Explorer 6.0 and FireFox 1.0 browsers when they log into their account:

Although SSL is widely used to allow users to securely log into a web site, it is not the only method that modern browsers support. Another method, which is just as seccure, is called Interated Windows Authentication (hereafter called IWA). Most web browsers (all versions of Internet Explorer, and recent versions of Gecko-based browsers such as FireFox 1.0) support IWA.

Whereas SSL uses the widely recognized gold lock visual cue to indicate to the user it is safe to type your password, IWA uses a different (but just as valid) visual cue to reassure the user it is safe to type your password. Some users have recently raised the concern that since the visual cues are different for the SSL and IWA methods, that some reassureance of the safety and validity of IWA be given to the GLAST community, which is the purpose of thie article.

How IWA works

Roughly speakig, there are two ways to authenticate a user to a web site called Forms Based Authentication and Browser Based Authentication. The method many users are familiar with is Forms Based Authentication, which is when a form embeded in a web page prompts a user for their username and password over an SSL connection to the web server. The user types their username and password into the web form and clicks the submit button which sends the credentials to the web server over the encypted SSL channel for authentication. It is important to point out that the user's web browser has no idea that the user is logging into the web site - all that the web browser knows is that it is sending information to the remote web site over an SSL channel.

The Browser Based Authentication mechanism is different in that it uses the browser's built-in functionality to authenticate a user to a web site. It is important to point out that the user's web browser fully participates in logging the user into the web site - a completely different approach to the Forms/SSL method. Since the browser knows it is logging the user into a remote web site, it can use a built-in dialog box to ask the user for their username and password. Here are the dialog boxes used by Internet Explorer 6.0 and FireFox 1.0:

For both the Forms/SSL and Browser based authentication mechanisms, it is important that the user trusts the web site they are logging into. For example, just becasue you use an SSL encypted form to send your username and password to a remote web site doesn't mean that your password is safe. If the programmer who created the remote web site is inexperienced in security issues, they could easily do something to compromise your password without intending to do so. Becuase security is so important and so easy for a programmer to get wrong, the Department of Energy requires SLAC to not allow programmers to ever ask a user for their username and password unless they obtain special permission from the lab.

IWA is an example of Browser Based Authentication since it is a feature that must be bulit-in to the browser. As with Forms/SSL, the user must trust the web site they are sending their credentials to. Since http://glast-ground.slac.stanford.edu/ is an official GLAST web site that has been vetted by SLAC Computing Services (SCS), GLAST users can trust that it is safe and secure to provide their SLAC credentials to the web site. In the dialog boxes above, the visual cue that it is safe for the user to enter their username and password into the dialog box is the HTTP address in the dialog box. it is clear to the user that they are connecting to the web site http://glast-ground.slac.stanford.edu/, and since they trust this web site they can safely enter their username and password.

Under the Covers of IWA

For those of you iterested in the details of IWA, I'll walk you throuh the HTTP headers of a web browser connecting to http://glast-ground.slac.stanford.edu/ so that you can see how the cyptographic exhage works. In each of the following diagrams, the HTTP header sent by the browser to the remote web server is shown first, followed by the remote web server's response back to the browser.

Note that the web server repponds that the browser it is not authorized to access the web server (the {[HTTP/1.x 401 Unauthorized}} tells you this), and that the only valid form of authentication that the web server will accept is IWS (which is what the WWW-Authenticate: NTLM line tells you). Since IWA is built into the browser (in this case FireFox 1.0), it prompts the user for their username and password. A hash of these credentials (not the credentials themselves) is passed to the web server (in the line Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=), which allows the web server look up the user in the Windows password database and to construct a unique encrypted challenge that the browser can only decrypt with the user's unique password. The long line of characters sent by the web server to the broswer (after the {{WWW-Authenticate: NTLM }} in the diabgram below) is the encrypted challenge:

Back at the browser, the browser decrypts the challenge with the user's password to get the answer to the challenge, which the browser then sends to the web server as proof that the user is who they claim to be. If the web server determines that the answer is correct, the web server sends the requested page to the browser.