text-only version
Distributed Authentication Documentation


Proposed Solution and Technical Description



This description of the proposed solution is directed toward the web site technical administrator. First, we describe the process in the time sequence in which it takes place. Next, we'll break it down into the components required for the project, followed by a description of the sequence of events from a user's viewpoint and web server action viewpoint. Lastly, we'll describe the requirements for using this service on your UCD web server.

How Distributed Web Authentication Works

When a user on a remote machine accesses a document space you wish to be secure, the netscape enterprise 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:

  1. The user, using an SSL-capable web browsers (enabled for token-passing), and new-style user name and kerberos password. (All new accounts created for past year).
  2. Distributed web servers (maintained by campus departments), utilizing Netscape API (for Netscape servers) or CGI method with PERL scripts (for non-Netscape servers).
  3. SecureWeb server (maintained by IET)
  4. AFS servers (securable, distributed file system maintained by IET - only writable from secure web browser and only readable from those servers that know access key or which are in an access control list)
  5. Kerberos DB authentication server (maintained by IET).
  6. Modified applications (news, mail).

Process from the user's point of view:

  1. User accesses the Internet via a third-party Internet provider.
  2. User launches an SSL-capable browser.
  3. User attempts to open a document that is secure on a local UCD server.
  4. [Transparent to user] Local server looks to see if user is already authenticated (has a valid cookie).
  5. If user is authenticated, the document is processed.
  6. 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).
  7. If all is ok, the document is presented.

Process from the local web server's viewpoint:
  1. If access to page is not restricted, no access control is in place.
  2. 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 (using either Netscape API or PERL script provided by IET).
  3. If the user's cookie is valid, the page is presented.
  4. 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.
  5. If even higher level of access control is required, server can check against local access database before presenting the page
  6. 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:
  1. A request for assistance is received from the local web server.
  2. The SecureWeb server contacts the kerberos database to authenticate the user.
  3. 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).


Requirements for using this software on your web server

If you are running a netscape server, you will need to install a custom netscape library, and configure your server to use that library. If you are running a server other than netscape, you will need to install a cgi script, and configure it for use on your system. In addition, you must be running PERL if you use the cgi script. There are three levels of security available, and the most secure version running on any server requires that your server system be able to read an AFS file.