Distauth: FAQ

What is the purpose of the distributed authentication?

The original, primary purpose of Distauth was to replace IP-address-based authentication for access to campus resources, with an equivalent that is transparent, scaleable, and distributable (portable and modular). The solution must provide a commonly-used infrastructure for multiple applications. Authenticated access to Web pages and UCD newsgroups were the top priorities.

During the process of development, the following secondary design goals were identified:

  • Support for authentication for access to campus site-licensed software, which may involve multiple cgi's.
  • As feasible, providing "hooks" to support authorization processes that are managed by Web servers (for locally-maintained authorization files), middleware such as Cold Fusion, or databases (Oracle, Access).
  • Generating authorization lists (files containing the UCD LoginIDs of students identified by course or CRN. This involves using the classlist information from BANNER, maintained by the Registrar's Office, in conjunction with UCD LoginID's from IET's Mothra database, and storing the LoginIDs securely in AFS space (Andrew File System, a distributed file system to which only authorized campus Web servers would have access).

What design principles were used in designing the solution?

In order to provide true infrastructure support, Distauth must be a general-purpose solution to a general problem; therefore it was designed as a gateway function, without dependencies on backend server or database processes. It doesn't matter how complex and interactive the backend server processes might be; once a user passes through the gateway (in the form of a variable), the authentication process has been completed, and has no further effect on user interactions with the server.

To what extent have the design goals been achieved?

The primary design goal has been accomplished: a distributed authentication service that replaces IP-address-based authentication has been developed and tested for over 70% of the campus Web servers (and for access to campus newsgroups).

The secondary design goals, in particular, "hooks" for authorization by databases, have been achieved to a lesser extent.

What are the key elements of the distributed authentication service as implemented?

The key elements are:

  • SSL-capable Web browser
  • UCDLoginID and kerberos password
  • Distributed Web servers with authentication scripts
  • SecureWeb server (maintained by IET; carries out Kerberos-style authentication)
  • AFS servers (securable, distributed file system maintained by IET)
  • Kerberos Database authentication server
  • Modified applications (news, mail)
  • Cookie (token)