Papers in PDF format

Every time a user tries to access a Web page in a secure database application, that user should be
authenticated. The secure loop is a method to verify the user at every such access.
In the following discussion, we assume that the connection between the client and the server is secured using
some protocol like Secure-HTTP (S-HTTP) [Rescoria 1996]. Discussion of the purpose and implementation of
such security measures can be found in [Netscape 1996b].
3.1 Necessary Database Tables
The secure loop requires a mechanism to maintain the list of authorized users and a set of special values,
called “tickets,” used to associate a user with a specific set of screens they can access at a given time. Our
implementation uses two relational database tables for this purpose: AuthUsers and Ticket.
The purpose of the table AuthUsers is to hold the list of authorized users, their passwords, and other
information that could be useful to the application administrators. The purpose of the table Ticket is to hold
the set of tickets that are valid for a specific user. It has at least three columns: Username, TicketValue, and
TimeStamp. Username uniquely associates a set of ticket values with a user. The tickets held in TicketValue
are random numbers generated at every Web access (see [Description of the Security Loop]). Ticket creation
times are kept in the column TimeStamp so that they can become invalid after a specific amount of time.
3.2 Description of the Security Loop
[Fig. 2] displays the general interaction between the user, the Web server, and the scripts that process form
data. The boxes in the shaded area represent actions that are done by all CGI scripts within the secure loop and
can therefore be encapsulated in a library common to all of these scripts.
3.2.1 Initial Authorization
In our implementation, every user is given a password granting them access to the database. This password is
encrypted and recorded into the AuthUsers table. When starting a database session, the first form the user
encounters is a login screen. When the login form is completed, the encrypted password is compared with the
AuthUsers table for that username. If the passwords match, the user is granted access to the application, a
random ticket is generated, and the user enters the secure loop. Otherwise, an error message is displayed.
3.2.2 Inside the Secure Loop
Every CGI script in the secure loop uses the following procedure:
1. Check Ticket in Database: The script parses the command line extracting the username and ticket. It then
executes a database query to ensure that the ticket is valid for the given username. If the ticket is valid,
then the user is authorized to continue. Otherwise, an appropriate error message is given.
2. Process Form Data (if applicable): This is where the processing of the form data can be done safely. This
could involve executing a query, updating tables in the database, or the like.
3. Generate Destination Ticket: A random ticket is generated, entered into the database and appended with the
username to any outgoing link of the page created in step 4. Since the ticket is random and the link
between client and server is secured, only the client and server know this ticket.