How Distributed Web Authentication Works
When a user on a remote machine accesses a document space you wish to be secure, a distributed
authentication enabled Web server checks for the existence of a specific cookie in the user’s
environment. If the cookie is found and deemed to be authentic, it grants access to the requested
document. If no cookie is found that is authentic, it passes the client to the U.C. Davis Web server
configured for granting and creating the required authentication cookie.
The user's Web browser asks the user for their Kerberos principal and password for authentication.
Since the server requesting this information is on a secure Web server, this information is encrypted
before being sent from the clients Web browser to server. The server uses the principal name and
password to verify that the user is who they say they are. If this verification succeeds, the server
then informs the user’s Web browser to set a cookie which will be transmitted to all Web servers in the
ucdavis.edu name space. Finally, having set the cookie, the Web server passes the client back to the Web
page which was initially requested by the user for access.
Upon returning, when the client’s cookie is checked and found to be authentic, access to the requested
document is granted.
Key Elements of the distributed Web authentication service:
- The user, using an SSL-capable Web browsers (enabled for token-passing), and a kerberos user name / password pair.
- Distributed Web servers (maintained by campus departments), utilizing one of the supported distributed authentication modules.
- SecureWeb server (maintained by IET)
- AFS servers (securable, distributed file system maintained by IET - only writable from a secure Web server and only readable from those servers that know access key or which are in an access control list)
- Kerberos DB authentication server (maintained by IET).
Process from the user’s point of view:
- User accesses the Internet.
- User launches an SSL-capable browser.
- User attempts to open a document that is secure on a local UCD server.
- [Transparent to user] Local server looks to see if user is already authenticated (has a valid cookie).
- If user is authenticated, the document is processed.
- If user is not already authenticated, a name/kerberos password is requested by the SecureWeb server, and a cookie is provided (user must accept to access restricted pages).
- If all is ok, the document is presented.
Process from the local Web server's viewpoint:
- If access to page is not restricted, no access control is in place.
- If access to page is to be restricted, the server looks for a cookie from the user's Web browser, and validates the contents of the cookie.
- If the user’s cookie is valid, the page is presented.
- If higher level of security desired, server can also look for and validate the AFS file associated with the user (server must have AFS access) before presenting the page.
- If even higher level of access control is required, server can check against local valid user lists, class lists contained in AFS space, or other control systems dependent upon the module deployed to the server.
- If the cookie is not valid or not in existence, the local Web server will contact the SecureWeb server for assistance in establishing authentication.
Process from the SecureWeb server’s viewpoint
- A request for assistance is received from the local Web server.
- The SecureWeb server contacts the kerberos database to authenticate the user.
- If the user is valid, the server passes a cookie to the user's browser, writes the AFS file, and redirects the user's browser (back to the original requested server).