Redirect Authentication Type Design

This document proposes a design for handling external authentication from a remote system such as SloanSpace.

The Big Picture

The redirect authentication system is part of our efforts to hook into existing infrastructure. Chances are good that new adopters already have a sign in system. We want to take advantage of that when possible. This system proposes a design for handling the case where central passwords are entereed into a central web application to which we will redirect the user for login.

OpenACS

After signing into OpenACs, users wishing to log in to another site will either browse to or be redirected to /auth-server/login. This script will generate and store a random string to be used by the the client system. It will also generate a nonrepeating integer to combine with the random string to create a login token. The integer, random string and OpenACS user_id will be stored in the database for later use.

create sequence auth_server_token_id_seq start with 1;

create table authentication_server_token (
    token_id                    integer
                                constraint auth_srv_token_pk
                                primary key,
    user_id                     integer
                                constraint auth_srv_user_id_nn
                                not null
                                constraint auth_srv_user_id_fk
                                references users,
    token                       char(40)
                                constraint auth_srv_token_nn
                                not null,
    consumed_on                 date
);

Other System

After database insertion, the user will be redirected to a particular URL on the other site with the unique key added as a URL argument. The client login page will make a request back to SloanSpace, sending the unique key. Sloanspace will try to match this key against a row in the database having a non-null consumed_on column. If a match is found, OpenACS with return a document with the logged in user's email address and perhaps their first and last names. It will also mark the token as having been consumed.