|
A Cookie-Based Scheme for Remote Access to CSE Web Pages |
|
 CSE Home |
About Us |
Search |
Contact Info |
"csecookie" is a web authentication scheme that is based upon HTTP cookies and the Kerberos authentication service. The basic idea is to use a brief SSL-encrypted transaction to allow users to supply their Kerberos login credentials securely, building an HTTP cookie that, crytographically signed by the web authentication server, is a tamperproof proof-of-identity that is transparent to both users and web applications.
The web login facility itself is here.
(A web tool for changing your kerberos password— access to which itself requires a web login— is here. An unauthenticated version is here.)
A document describing the distinction between your Kerberos credentials and those associated with other CSE accounts is here.
Several important pages on our CSE webserver are considered ``sensitive'' to the extent that we would rather not make them available to casual web surfers outside the department. [1] Access to such pages has traditionally been limited by placing restrictions on the source IP address of the of the browser making the request. For example, browsers within the .cs.washington.edu domain might be allowed access, while browsers from other sites are denied.
That simple scheme works reasonably well when users are working exclusively on-site. However, there is also a necessity for legitimate CSE users to access restricted pages from non-CSE hosts, sharply limiting the utility of IP-based authentication. Secondly, it is sometimes necessary for a web application to know the identity of the user. Finally, some resources are restricted to a subset of CSE users.
In the following paragraphs we describe a relatively secure scheme that allows such access.
The solution described hhere augments the current IP-address based protection mechanisms with the use of credentials which can be obtained by an external user after proving his/her local identity. Proof consists of providing a local username and password. The authentication process takes place over a secure (SSL) channel to a trusted local web server. In return the user receives a tamper-proof credential in the form of an HTTP cookie that is presented when accessing pages.
The cookie contains, among other things, the user's CSE identity and an expiration time after which the credentials must be renewed (currently ten hours). It is tamper-proof because it has been signed by the trusted web server which initially verified the user's identity. The signature consists of an MD5 checksum of the cookie's contents encrypted in a key known only to the web server. On a subsequent page access, the checksum of the cookie is calculated and compared against the original, decrypted checksum. If the two checksums do not match, the cookie is invalid and access is denied.
While the cookie is tamper-proof and non-forgeable (the user can neither change their identity nor conjure a valid cookie from thin air), it can be ``sniffed.'' For performance and organizational reasons, cookies are not constrained to travel over secure channels. Thus a third party monitoring network traffic could obtain a copy of the cookie and replay it, thereby assuming the guise of a legitimate user. Despite this shortcoming, it is felt that cookie scheme (and the nature of the content it will be used to protect) has an acceptable risk/benefit ratio. The effect of a ``sniffed'' cookie is mitigated by enforcing an expiration time. And, the cookie is a ``session cookie''- it is discarded when you exit your browser (as users in a shared computing environment such as a computing lab will definitely want to do).
When a remote user attempts to access a credentials-protected page, he/she is redirected to an error document explaining that credentials must be obtained and containing a link to the cookie generation CGI on the trusted web server. The error document also explains that the authentication dialogue will take place over an SSL channel so that the user's password never travels in clear-text over the network. As a consequence of setting up the SSL connection the user may be prompted by the browser to accept a certificate from the ``untrusted'' signer of the certificate. This is harmless and the certificate should be accepted.
At the end of the authentication procedure, the granting of credentials will be confirmed. The user can then click on a link on the confirmation page to proceed to the originally-requested page.
Users wishing to grant remote access to pages can do so in the following manner.
A standard, IP-address restricted .htaccess file looks like:
To allow access from both CSE hosts and any authenticated remote users, the file is changed to:order deny,allow deny from all allow from .cs.washington.edu
If only certain remote users are to be granted access, the require line could be changed to:Satisfy any order deny,allow deny from all allow from .cs.washington.edu authtype CSENetID require valid-user
Other combinations of access control directives are also possible, perhaps providing access based upon named groups of users.require user <username1> <username2> ....
Controlling Access to Your Documents provides more information, and includes form-based access to tools that will create access control files for you.
An extension to the login service uses a persistant HTTP cookie to cache the username across browser sessions. The idea is to save typing for users on private machines. It works like this:
Part of the CSE implementation is based on code generously made available by UW C&C's Pubcookie project.
 |
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] |