Better Web Login

CSE Home

About Us

Search

Contact Info

New Web Login  Legacy Web Login  A Cookie-Based Scheme...  Controlling Access    to Your Documents

October 24, 1999 Summary The lab is changing some details of how you obtain the CSENetID "web login" cookie that allows you to access certain web resources. This document describes how and why without apology for giving deep technical details. CSE uses a proprietary and relatively new authentication mechanism to control access to certain mildly-sensitive web content. It implements a "web login" that we call "CSENetID." Key characteristics include you use your kerberos login credentials (username and password) to authenticate the web login "ticket" is carried in an HTTP cookie, signed by the web login service using public key encryption the ticket expires after a preset period, currently four hours See A Cookie-Based Scheme for Remote Access to CSE Web Pages for details. The current scheme involves visiting a cookie-generating CGI script on a secure (SSL) server that is protected by mod_auth_kerb authentication directives. Because we lack kerberized browsers, mod_auth_kerb is used in "basic auth" mode: a basic auth challenge is sent to the browser, which causes the browser to pop up a dialog box for the password and username. The browser retries the request, supplying the user credentials this time, and, if mod_auth_kerb validates them, access to the CGI is allowed. Running the CGI returns a cookie. This scheme has the advantage that the CGI is simple to construct: all it needs to do is ask an external program for a signed "ticket," which it then returns to the user in a cookie response header. The disadvantages, in decreasing order of importance, are these: Common browsers cache basic auth credentials, so an expired cookie never requires a meaningful reauthentication step. The effect is that cookie expiration is useless for security, and at best an inconvenience for the user. At worst, it's confusing to the user. The security lock icon on the browser frame only closes when a user has successfully accessed an SSL-secured resource. That's only true after they successfully authenticate, not while they are entering credentials into the basic auth dialog box. That confuses naive users. We need to build mod_auth_kerb into the web server. That's a heavyweight module that also adds complexity to the build process. An extra Unix process is required for each authentication, because the cookie generating program is a distinct program from the CGI. A better solution- the one the lab has created a draft implementation of- is to build a standalone CGI that presents its own form for gathering user credentials. Such a CGI needs to link against both kerberos and the PGPTools libraries, which means that it pretty much needs to be implemented in C. It's much more complicated than the Perl CGI that does the web login now-- its chief disadvantage-- but it has these advantages, in decreasing order of importance: Login credentials aren't cached (unless a boneheaded IE5.0 user specifically asks for it). That means that when a cookie expires, the user needs to reenter their creds. The security lock icon is closed while credentials are entered. The web server is simpler to build and lighter weight. One authentication, one process. There are some minor additional features of the new CGI: For those with an existing and valid (not expired) cookie, there is the opportunity to destroy the ticket. This is expected to be most useful for users that are browsing from a shared host that don't wish to exit their browser session to destroy their credentials. The user can view the expiration time of their ticket. The draft implementation is available as https://www4.cs.washington.edu/cgi-bin/wlogin.cgi. Scott Rose October 24, 1999

	Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to webmaster@cs.washington.edu]