|CSE Home||About Us||Search||Contact Info|
In November 2010, CSEcookie became an HTTPS-only technology, meaning that it can only be used to secure resources that are on encrypted network channels. This change was motivated by the need to use the authentication scheme with more sensitive information, such as cloud-based services, than was originally anticipated. This can break legacy links. Information in this document explains how to mitigate.
Questions? Please contact support.
"CSEcookie" is a web authentication scheme that is based upon HTTP cookies and the Kerberos authentication service. The basic idea is to use an 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.
CSEcookie can only be used to protect HTTPS resources.
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.
Various services and pages on the CSE network are intended for access only by internal users, and some services need to know the specific identity of the user that is accessing them. Users may browse from arbitrary locations. What is needed is a secure scheme that allows CSE users browsing from arbitrary locations to access and be identified to such resources.
CSEcookie is based upon 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/HTTPS) 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 web resources.
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.
The cookie is a ``session cookie,'' discarded when the user exits the browser (as users in a shared computing environment such as a computing lab will definitely want to do).
The cookie is (as of November 2010) a ``secure cookie,'' provided only to encrypted (SSL/HTTPS) resources.
When a remote user attempts to access a protected page, s/he 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.
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 resource.
Providing a file called
.htaccess in a directory containing
content to be protected will establish auth policy.
For example, to allow access from both CSE hosts and any authenticated remote users, the file might read:
satisfy any order deny,allow deny from all allow from .cs.washington.edu authtype CSENetID require valid-user
If only certain users are to be granted access, instead specify:
authtype CSENetID require user <user1> <user2> ... <usern>
HTTPS is enabled on an as-needed basis on CSE web servers. In particular, many Apache httpd virtual hosts don't have it. Need HTTPS to support CSEcookie on a host that lacks it? Please contact support.
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 the Pubcookie project created by UW Information Technology.
Computer Science & Engineering|
University of Washington
Seattle, WA 98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to firstname.lastname@example.org]