University of Florida GatorLink authentication support
Overview of GatorLink authentication

The GatorLink login server

A Unix server location at NERDC is the home for GatorLink login services and is named:

Functions available at this address include:

  1. A GatorLink login CGI script.
  2. A GatorLink logout CGI script.
  3. User web pages for the display of session logs.
  4. GatorLink customer service web pages for display of session logs.

The GatorLink login CGI script

The GatorLink login script is invoked with this URL:

When it executes, it will:

  1. Verify the user's username and password.
  2. Generate a GatorLink HTTP cookie.
  3. Record the existence of a GatorLink web session.

Although the CGI script can be called directly using the above URL, it is more useful when it is used as the action URL in a form on another web page. When used this way, any other web service can provide a GatorLink login as one of its pages.

The web service using the login script should code a form so that:

A typical form in a web page might look like this:

Once the user has succesfully entered a GatorLink username and password, a link on the login screen lets them return to the originating web site. The original web service can then use the GatorLink cookie to determine the web client's GatorLink username.

The GatorLink logout CGI script

Although a GatorLink web session can be effectively "logged out" by exiting from the browser or otherwise destroying the cookie, this does not erase the session information stored on the GatorLink server. The only way to completely destroy the session is to use the GatorLink logout CGI script.

This script is at this URL:

The script can also be invoked using a form with the same hidden return field used by the login script. This will give the user a link to return to after the logout.

The GatorLink cookie

An HTTP cookie is used to maintain information in a user's browser that can identify the current GatorLink web session.

A successful login at the login script causes an HTTP cookie to be generated and sent back to the user's browser. A typical cookie will look something like this:

The value of the cookie consists of two long strings separated by a colon. The two parts are, in order, the session id and the state key.

The id part is a a unique identifier for the user's session. It is generated when they log in and will have the same value until they logout. It could, if desired, be used as a tag for additional state information to be stored by a web service.

The state part can change during a GatorLink web session. There is, at any instant, only a single valid state value for a GatorLink session.

The id and state values in the cookie have no meaning and do not contain any encrypted content. Each is the hex representation of a 128 bit MD5 hash. The hash is generated from information stored at and only known to the login server.

When the cookie is sent back to the browser, it has these additional qualifiers:

These qualifiers restrict the use of the GatorLink cookie to UF web sites.

Note that there is no expiration time for the cookie. The usual behavior for a browser is to forget the cookie when the browser is closed if the cookie has no expiration. For most browsers, closing the browser is equivalent to logging out.

Note: The authentication script currently generates and additional cookie with the name UF_GatorLinkUser. This cookie is being generated temporarily for compatibility with an other authentication system. It is not used by the current authentication system.

The authentication server

The only way to determine the username and IP address associated with the value of the GatorLink cookie is by calling the authentication server. When a CGI script for a web service is executed, it can determine the username for the connecting browser by following these steps:

  1. The GatorLink cookie is located in the HTTP headers sent by the connecting browser and the value extracted.
  2. A connection is opened to the authentication server.
  3. Information from the GatorLink cookie and optionally the IP address of the browser is sent to the authentication server.
  4. A reply is read from the authentication server.
  5. The reply from the server may consist of a username and IP address. If the IP address sent back by the server matches the IP address of the connecting browser, then the script can assume the specified username is logged in.

The authentication server is available at this address and port:

All transmissions to and from the server must have a newline character as a terminator.

No initial message is sent by the server to the client. The client sends a request to the server in one of two formats. The first format consists only of the id and state from the GatorLink cookie:

If the id/state pair represents a current session, the server responds with a single line that looks like this:

It is the web service's responsibilty to determine that a web browser request has originated from the returned IP address.

An alternate format for the request from the client to the server also contains the IP address of the browser:

If the IP address and id/state pair represents a current session, the server responds with a single line that looks like this:

The server could also send back one of two strings:

Additional features of the authentication server

Two additional features of the authentication server and login CGI script can be used to enhance the sercurity of the GatorLink web session. These two features are:

  1. An "idle timeout": if the user's web session appears to be idle, then they must reenter their password to continue.
  2. A variable state key: the state part of the GatorLink cookie can change as frequently as a web service desires. Changing the state key invalidates old versions of the GatorLink cookie.

Enforcing an "idle timeout"

A website may wish to assume that a web session that has been idle for some number of minutes is unusable until the user reenters a password. The client can optionally specify a maximum idle time in the transmission to the authentication server. This value is specified as an integer from 5 to 60 and is sent as an additional part in the request to server. In the two forms of the request to the server, "n" would specify the idle time value:

The idle time is the number of minutes since the authentication server correctly identified a user to some remote caller. If the idle time is greater than the value supplied by the client, then the session is considered to be idle. The server will not return the user identification, but will instead send back the string !IDLE. See Reauthentication below.

If no value is specified, the authentication server assumes a value of 60 minutes.

Generating a new state

A weakness of using a value passed in a cookie from the web browser to the web server for identication is that the cookie value can be seen by any other web site. There is the possibility that the identification value could be trapped and then used by another person. They would need to use that identification from the same location, but many computers are in public or are shared and that is not unlikely.

The caller of the authentication server has the option of requesting a new state value by adding the word "new" as the last part of the transmission to the server:

(The idle time value can be specified or left null.)

When the server's response indicates a current session, the state value part of the response is the new state. For this new state to be effective, the client must take the responsbility of using this value to send back a new HTTP GatorLink cookie to the web browser.

The id and old state will now no longer identify a user. However, the session can be resumed with the entry of a password.

Reauthentication

If a web service has determined that a user web session is "idle", they can have it reactivated by invoking the same login CGI script. If the user's browser appears to have a current session, it will be reactivated if the correct GatorLink password is entered.

Automatic logouts

The login server periodically scans all currently known sessions, and those that indicate no recent activity are deleted. This means that the authentication server can no longer determine the username and address for given id/state pair.


Return to GatorLink authentication support home page.

Last revision: November 30, 2000

For assistance, contact the UF Computing Help Desk:   (352) 392-HELP or helpdesk@ufl.edu
 


Center for Instructional and Research Computing Activities
E520 CSE • University of Florida • Gainesville, FL
University of Florida