Authentication strategy

CS 284 (CSA), Spring 2005

Our authentication strategy for CS projects involves the following elements:

• Use IIT-administered web-based authentication, e.g., "account services," so that our code can't possibly see a password.

• When user enters a valid username/password, an authentication process running on IIT-administered web server interacts with the client and server programs and with a database (located on arachne) to establish a secure socket connection between the application's client and server that both client and server can trust. This authentication process operates as a trusted third party for both client and server; each party provides the others with tokens (e.g., enormous, short-lived random numbers) across encrypted connections that establish identity beyond all reasonable doubt.

• The secure socket between client and server is used for all subsequent client-server interactions and persists until one of them expires.

• This mechanism is intended for both the present CS 378 project and for future CS projects; projects using Java can reuse the same code produced for the present project.

The team of Ted Johnson, Aubrey Barnard, and Robert Crawford have developed this strategy (Fall 2003) under the general direction of R. Brown, based on an idea of Brown's while directing Barnard over Summer 2003.

• See the team's planning documents for more information. The overview is particularly helpful.

The security of this plan depends on the following basic assumptions.

• Existing socket connections between two programs cannot be taken over by another program without root privileges on an involved machine.

• Root privileges are trustworthy.

• Username/password combinations are known only to appropriate persons.

• Encrypted connections (e.g., between client's browser and IIT server; SSL sockets between authentication process, client, and server; between server/authentication process and arachne database) can be trusted.