Identity Management Services

We will start by defining terms, giving an overview of the scheme, then by giving a detailed view. We will then explain why each part of the scheme is necessary. Finally, we will briefly describe the likely future for web-based authentication at KU.

Definition Of Terms

Names that refer to data are italicized in this glossary and in the protocol outlines below.

Application: One or more CGI programs that share login information such that if a user logs into one CGI, the information is cached and shared among the other CGI programs in that application. In our context, these programs must share a common URL prefix.

Application Cache: A simple indexed file where the login API saves client information for future visits to the application.

Application CGI: A CGI program that either is, or is part of, an application using the authentication service.

Application Name: The initial URL text shared by all the CGI programs in an application. All URLs beginning with the same application name text are considered to be part of the same application.

Application Server: A server machine running at least one application that uses the authentication service.

Authorization Criteria: The criteria that a user must meet in order to be authorized to use an application.

Cache ID: A unique identifier for a login session usually composed of the initial application CGI program's process ID and the time of day.

Client: A web browser that accesses an application CGI page.

Client Certificate: The SSL certificate issued to the application developers when they registered to use the authentication service, used to verify the application to the Login Server CGI.

Client Information: The particular information about the client that the application developers requested when they registered to use the authentication service.

Client Random: A 64-bit random number stored in the application cache and in the login cookie. Used to prevent attackers from guessing a Cache ID and assuming a client's identity. Called a "secret" because it's only known to the browser and to the application.

Authentication Service: The service provided by the login server and API such that a CGI can get access to client information based on the client authenticating with their online ID and password.

Login API: A library called by the application CGI to check authentication, retrieve the client information, and so on.

Login CGI: The CGI program that prompts for the client's online ID/Password and then verifies it. This runs in mod_perl to minimize the number of processes.

Login Cookie: A secure cookie stored in the client browser for the duration of a session. It saves the Cache ID between accesses of the application pages. It also contains the Client Random secret.

Login Server: The server machine running the login web pages. It needs access to the online directory information and needs to be able to authenticate online ID/Password combinations.

Login Server CGI: A CGI program responsible for returning the client's information to the application. This will run in mod_perl to minimize the number of processes.

Login Server Query Cache: A place to temporarily store the client's information between redirecting from the login CGI back to the application CGI and the login API requesting the information.

Online ID: The client's username in the iPlanet LDAP server. Used for logging into applications.

Password: The password for the client's LDAP username. Used for logging into applications.

Server Certificate: The SSL certificate issued to the login server. This is used by the client and by the login API to make sure they're talking to the real login server.

Slide Show

Here is a short Powerpoint slide show illustrating the steps taken to authenticate via Argus

Perl API Slide Show

Perl API Slide Show

Detailed View

1. The Client makes a reference to an application CGI.
2. The Login API in the CGI
   1. Checks for a login cookie for this application. If the cookie is found, skips to step 8. Otherwise it continues, since the user has not been identified.
   2. Generates a unique Cache ID and a Client Random secret.
   3. Stores these values in a client login cookie using the Set-Cookie HTTP response header. The Set-Cookie header
      1. Omits the expires keyword, so the cookie is recorded only in the client's memory and lasts only for the duration of the current browser session (less if reset by the application that created it.)
      2. Omits the domain keyword, so the client will provide the cookie only to the application server that created it.
      3. Includes the secure keyword, so the cookie will not be provided to a non-SSL HTTP server running on the same machine as the Application HTTPS CGI.
   4. Saves the client's IP address and Client Random secret in the application cache indexed by Cache ID.
   5. Redirects the client (using the Location HTTP response header or an intermediate screen) to the Login CGI on the Login server, including the return URL for the application CGI and the Cache ID passed as a query string.
3. The client sends the request from step 2e to the Login CGI on the ID server.
4. The Login CGI on the ID server returns a form requesting the online ID and the password from the client.
5. The client sends the online ID and password in a POST query to the Login CGI on the ID server.
6. The Login CGI on the ID server
   1. Authenticates the online ID/password pair against the domain controller
   2. Caches the desired client information indexed by the application name and Cache ID in the Login Server Query Cache for access in step 9 by the Login Server CGI on the Login server.
   3. Returns the client to the original application CGI with the HTTP Location response header or an intermediate screen.
7. The client resends the request to the original application CGI, but this time there is a login cookie.
8. The Login API in the application CGI
   1. Senses the login cookie it set in the client, and verifies its Client Random secret with the value stored in its cache in step 2d above. Checks to see if the client info is already cached. If so, skips to step 10c.
   2. Opens an HTTPS connection to the Login Server CGI on the Login server, passing its client certificate to verify its right to the information. Sends its application name and the Cache ID in a POST query to the Login Server CGI.
9. The Login Server CGI on the Login server
   1. Verifies the client certificate, which tells it which application is making the request.
   2. Retrieves the client information from the Login Server Query Cache for the requested application name and Cache ID and deletes it from the Query Cache.
   3. Sends a response containing the client information.
10. The Login API in the application CGI.
    1. Verifies that the server certificate matches the Login server's certificate, thus checking to make sure we've queried the real Login server.
    2. Records the client information, client IP address and Client Random secret in the Application Cache (indexed by Cache ID) for use in subsequent interactions with the client.
    3. Returns the client information to the application CGI caller.
    4. The Application CGI returns the requested document to the client.

Click to see a larger version of this diagram.

Salient Features

The people responsible for an application must register with us to use the authentication service. They specify the initial URL string that identifies the application, the authorization criteria to authorize users to use their application, and the client information to be returned for each user.

The login page notifies the user of the particular application that is requesting authentication, and also can display a list of all applications that are registered. This way, the user can go to a known good page and request the list of registered applications and make sure the one requesting his or her information is in the list.

A user authenticates for each Application visited during a browser session (though not for each CGI in that application). This reflects our desire to leave the decision on the time to reauthenticate in the hands of applications, and of notifying the user of the identity of each application that requests his or her ID.

The application sees only the client information that the application requested when registering to use the authentication service.

All the transactions must use SSL to make sure that no program is sitting in the middle collecting information. The connection between the Login API and the Login Server CGI must have both a client and a server certificate to ensure that one or the other isn't an interloper. We don't currently restrict the SSL key length, and maybe we should.

The client certificate does not have a password, which is a security risk, but there's no way to provide a password from within the login API so we're stuck. We could use the server certificate on application servers where all the users are under the same management, but not on a central multi-user server such as Lark or Raven. If multiple applications use the same certificate then they can access each other's client information via the login server CGI.

It is possible that support for passing client certificates is not good enough to port the API to some platforms. We could encrypt the cache ID in the POST request using RSA (or something like it) to ensure that the application is who they say they are.

The initial request must be to the application CGI rather than to the Login CGI because otherwise we can't load a secure cookie that is only available to the application. The cookie must be a secure cookie with a path to the application CGI specified so that it is not available to other machines or to other applications on the same machine.

The Client Random secret discourages a different browser from the user's from being able to guess a Cache ID and impersonating the client. It's possible that 64 bits isn't big enough. It could easily be made larger.

The Login CGI must prompt for the online ID and password instead of the application CGI, because otherwise the application CGI could collect passwords.

The ways this could fail, so far as I know, are (1) a successful attack on SSL, (2) a successful attack on the unpassworded client certificate key, (3) a successful guess of a cache Id/Client Random pair, (4) someone creating a page that redirects to a page that looks like the login page and collecting passwords.

Future Directions

In one word the future direction can be described as Shibboleth. This is the Internet2 system that provides interrealm authentication, but it can also be used for intrarealm authentication. If used in that manner, the need for a separate WebISO is much reduced.

Author

Written by Kathryn Huxtable <khuxtable@ku.edu>. As with most Web documents, this is a work in progress and may change at any time.

$Id: index.shtml,v 1.5 2006/01/23 16:43:26 huxtable Exp $