An instantaneous introduction to authentication using Argus

The following diagram shows a WWW client running on a desktop system, Computer A, interacting with two servers: An HTTP server running on Computer B and an HTTP server running on Computer C.

The client running on Computer A gets a document, stored in a file named docu1.html, from the HTTP server running on Computer B. This document contains a link to another document, stored in a file named docu2.html on Computer C. The Uniform Resource Locator (URL) for that link might look something like:

http://ComputerC.domain/docu2.html

If the user activates that link, the client retrieves the file from the HTTP server running on Computer C and displays it on the monitor connected to Computer A.

The HyperText Transfer Protocol defines communication between the client and an HTTP server. The following example shows what an HTTP exchange between a Lynx client and an HTTP server running on Computer C might look like as the client fetches docu2.html.

The client sends the following text to server:

Finally, the client sends a blank line indicating it has completed its request.

The server then responds by sending:

Things to note here:

• Client and server headers are RFC 822 compliant mail headers.
• A Client may send any number of Accept: headers and the server is expected to convert the data into a form the client can accept.

Executing "scripts"

The diagram below shows an hypertext document on Computer B with a link to a file on Computer C that holds the CGI program that will be executed if a user activates the link. This link is a "normal" http: link, but the file is stored in such a way that the HTTP server on Computer C can tell that the file contains a program that is to be run, rather than a document that is to be sent to the client as usual.

When the program runs, it prepares an HTML document on the fly, and sends that document to the client, which displays the document as it would any other HTML document.

Such programs are sometimes called HTTP scripts or "Common Gateway Interface" (CGI) scripts. Note that CGI scripts may be written in scripting languages (like Perl, TCL, etc.) or in any other programming language (like Java, C, Pascal, Basic).

On some HTTP servers these CGI programs are stored in a directory called cgi-bin, and so they are also sometimes called "cgi-bin scripts."

Here is a simple Perl program that can be run by an HTTP server when it receives a request for the file containing the script. When it runs, this program builds an HTML document containing the current time and returns the document to the WWW client that requested it.

The program is stored in a file named "date", in a folder called "scripts". When a user activates a link that points to this script, the Web client will generate an HTTP request that might look like:

Executing a Script via an HTML Form

A set of tags was added to HTML to direct a WWW client to display a form to be filled out by a user and then forward the collected data to an HTTP server specified in the form.

To process such forms, servers were modified so that they could start the CGI program specified in the form and pass the collected data to that program, which could, in turn, prepare a response (possibly by consulting a pre-existing database) and return a WWW document to the user.

The following diagram shows the various components of the process.

When this form is "submitted" by clicking on the "Date" checkbox and the "Submit" button, the information sent to www.ku.edu by the client will resemble:

The MIME-type application/x-www-form-urlencoded means that the variable name-value pairs will be encoded the same way a URL is encoded. In particular, any special characters, including puctuation characters, will be encoded as %nn where nn is the ASCII value for the character in hexidecimal. (Note newer browser will probably use the MIME type "multipart/form-data" in place of "x-www-form-urlencoded".)

Here is a Perl program that could process such a query:

Using the GET Method

The server script can unpack the data shipped in the URL somewhat as it can unpack data sent via the POST method. In fact, the Perl CGI package can accept data sent via either mechanism.

The ability to append data to an arbitrary URL makes it possible to construct HTML anchors that send data to server scripts when they are activated. This allows document creators to prepare "canned queries" within their documents, something that is not possible with the POST method.

Redirection is a critical component of the Argus Authentication mechanism. Server scripts using Argus Authentication redirect initial browser requests to the Argus server for authentication, and the Argus server redirects the request BACK to the original script if authentication is successful.

Note that the redirection can be tricky, especially if you want to relay form arguments to the relay target. If the date-OR-time.pl script were to redirect a user, it MIGHT have to build a redirection line containing the arguments passed in the URL, as in:

Cookies

Cookies may posses a variety of attributes, but the general syntax for a cookie is:

• NAME is the name of an attribute,
• VALUE is the value assigned to that attribute,
• DATE tells how long the cookie should be considered valid,
• path tells which programs in the server's file system should be allowed to access a specific cookie,
• DOMAIN_NAME tells (basically) which computers can receive a cookie (the default value is the server that sent the cookie), and
• "secure" indicates whether the cookie must only be transmitted over a secure connection.

Cookes are used by Argus to exchange similar information so users can access a wide variety of University application without having to identify themselves to each new application. In particular, cookies are exchanged:

• between a user's browser and any application using Argus authentication, and
• between a user's browser and the Argus server itself.

The KuPortal modules provided by ACS for use with Argus manage cookies for Argus-enabled scripts, so programmers can usually ignore them. However, to understand the overall process you must have a general idea how of cookies are being passed around "under-the-radar."

This script interacts with the KuPortal module via the user_status method within the KuPortal module. For more information about KuPortal methods see the online documentation.

Prior to using this script from an HTML form, the action attribute of the form tag must be changed to specify the use of secure HTTP, as in:

Whenever anyone tries to access the script through the HTML form, user-status will be called and one of two things will happen:

• The script will return the requested information to the browser, because the browser has already been used to log in to Argus within a set time period, or
• The application script will NOT return the requested information, but will, instead, redirect the browser to the logincgi script running on the Argus server.

The page sent by argus.cc.ku.edu will request that the user login, by entering their online ID and its password on a form. When the user supplies the requested information, the Argus logincgi script will redirect the browser back to the get-date-OR-time.pl script and the browser will include the cookie just received from the the Argus-enabled application. The application will use information sent in that cookie to request specific user information directly from the Argus server.

The application can then tell whether the user's account is one of the "authorized" accounts (namely "grobe" or "khuxtable"). If not, the information they requested will NOT be delivered, and the user will receive an apology in its place.

If the user has logged in using one of the "authorized" accounts, the script will execute, but the requested information will NOT be delivered because the GET parameters are lost during the redirection process. The returned page will say that "Neither date nor time were requested."

To finally get the information, the user must press the "Back" button on the browser to return to the get-date-OR-time.html Web page and resubmit the request, which will then be satisfied.

For values passed through GET parameters, simply pass the query string from the URL as the fourth parameter in the user_status call, as in:

The problem is more complicated for POST arguments for several reason:

• POST arguments may be too large to be passed as part of a URL. (Most servers have URL size limits.)
• There may be too many POST arguments to fit in a URL.
• Files may be passed through the POST mechanism.
• There may be some overlap in POST and GET argument names that must be handled carefully by the script.

Having saved script arguments is just part of the process, however. The program must then be modified to check for the presence of a temporary_file_name argument when it is started. If it finds a temporary file, it must then read the contents of the file, assign them in appropriate variables, and call user_status again to get the user information required by the program. This call will not cause another redirection to the Argus server unless the session timeout is set to zero or some very small number of seconds; it, instead, only get information from the local cache.

Here is a version of get-date-OR-time.pl that uses this approach:

Likewise, if you log in to Argus while using the get-date-OR-time application, and then also begin using the Kyou portal where you log OUT, you will no longer be able to use get-date-OR-time (without logging in again) after get-date-OR-time exceeds its 30 minute session timeout.

Every time get-date-OR-time runs, it will check to make sure that you have authenticated, but will ask Argus if you are STILL logged in only every 30 minutes. That is, when you log out of Argus, there is no notification to get-date-OR-time that "Elvis has left the building." get-date-OR-time will not realize you have logged out until it conducts its periodic check.

Also, if you open another browser on your desktop computer while you are still using the first browser, or even another "instance" of the same Web browser, you will be asked to log in to Argus again, even though you are already logged in via the first browser or browser instance.

Argus was named after the figure of the 100-eyed herdsman in Greek mythology, and when you log in, you become a member of the herd that Argus is watching. Or, more accurately, the browser instance you are using becomes a member of the herd. That browser will be allowed to graze on various Argus-authenticated applications until logout, or some minutes past logout depending on how often each application checks for session viability.