Distauth: Form-based Distauth Documentation

Form-based Distributed Authentication Functional Specifications Version 1

The goal of the Form-based login application is to provide an effective way to log out of a Distauth-enabled web application by avoiding the use of browser-cached passwords that are a side effect of basic http authentication. The best way to accomplish this is to use a form so that the login userID and password attributes are not cached in the web browser. By avoiding the caching of userID and passwords, the Form-based login application makes it possible for authorized applications to completely log out users by invalidating authentication cookies.

In order to maintain compatibility with existing Distauth-enabled applications, an additional cookie (DA1) will be created upon visiting the login form as well as a cookie identical to the existing Distauth cookie (AuthUser). The DA1 cookie contains a time stamp and an indication of the login method used (initially, Kerberos username and password will be the only method available) so that client applications can enforce a custom authentication policy.

AuthUser Cookie

UserID IP Address Information Flag file value from AFS file system

DA1 Cookie

Unix Time Stamp Authentication method

Deployment of the Form-based login application requires both additions and changes to modules running on the Distauth servers (secureweb.ucdavis.edu) and client application servers. Secureweb needs to set a new cookie in addition to the AuthUser cookie during the authentication process. The various client modules require modification to check for the existence of the DA1 cookie and enforce any custom authentication policy - limited to time-based expiration in the first implementation.

The Process

  1. In general, the process for access to secured web sites does not differ significantly from the end user's perspective. The end user submits a browser request to a Distauth-protected web site.
  2. Consistent with the current process, the secured server redirects to SecureWeb if the requestor's browser has an invalid or no AuthUser cookie. A form-based application will also redirect if the DA1 cookie is absent or in violation of application authentication policy (e.g., time expired).
  3. SecureWeb displays a form similar to the one below (Figure 1), asking for a Kerberos ID and password. The new Distauth Form-based module uses a URL separate from the basic auth SecureWeb URL.

    The form used in this application has a look and feel distinctly different from basic auth authentication dialogue.


    Figure 1. Possible new form proffered by SecureWeb for logging in.
  4. The user will supply authentication information.
  5. The Distauth Form-based module will create an AuthUser cookie and, per its new functionality, will also create an additional cookie (DA1), which can be erased to affect a log out by an authorized application.
  6. The Distauth Form-based module will complete all the other steps normally associated with authentication using the KDC and AFS.
  7. Applications that wish to take advantage of the Form-based login application can be modified to include a logout button. Such a button would be tied to a URL that will erase all authentication cookies and redirect the browser to a selected location. The Middleware team has developed a URL with this functionality and it is available to interested clients.

    Clients wishing to use the logout functionality have two options:
    1. Use the URL https://securweb.ucdavis.edu/form-auth/logout. This will remove the DA1 and AuthUser cookies and then redirect to a basic "logged out" information page.
    2. Append a query string and any valid URL to the URL above and after erasing the cookies, secureweb will redirect the browser to the supplied URL. For example: https://secureweb.ucdavis.edu/form-auth/logout?http://my-servers-logout-page

Additional Considerations

Client side changes must be addressed case by case. The project must allow for backwards compatibility so that client servers familiar with the traditional cookie and browser cached user ID and passwords will not be disabled. Web applications that want to take advantage of the Form-based login feature must be changed to access the new DA1 cookie. Client software changes include but may not be limited to Apache, IIS, iPlanet, and Cold Fusion.

At the time of this writing a form-based apache Distauth.pm has been distributed which includes a configurable session time-out value. If the DA1 timestamp is older than the current time minus the timeout value, the user will be redirected to a new login page with an informational message notifying them of the session timeout. Other modules will be distributed as they become available.

Additional features that may be addressed in future implementations of this project include the following:

  1. Formatting, such as frames or information specific to a department, may be added to the Distauth Form and presented only for users from those departments.
  2. In the future, Secureweb may validate the DA1 cookie with a digital signature.
  3. We may include additional authentication methods besides Kerberos in future implementations.
  4. In future implementations, we may allow other information in the DA1 cookie for client applications to track for cookie currency. E.g., information that allows client applications to test for on-going activity from the end user, information that allows client applications to provide incremental authentication, and the like.