Athens single sign-on architecture

An unidentified user makes contact with an Athens registered Service Provider (DSP).

The web server intercepts the request and refers the user’s web browser to the Athens Authentication Point (AAP) with a packet of information containing the Athens DSP identifier and a return URL. Alternatively the resource may offer a specific named link eg ‘Athens login’ which performs the same function.

The user’s browser contacts the AAP which first time round will authenticate the user. If the user’s organization is registered for Local Authentication, the user will be referred to the local authentication system; otherwise the username and password are checked against the Athens Repository by the Athens Authority Server.

If authentication is successful, an Athens Single Sign-on session will be created by the Athens Authority Server.

A long term token is then created to preserve a record of the user’s session in the authentication domain of Athens. The timeout on this token is currently 8 hours. If the user already has an Athens Single Sign-on session, recognized by the Long Term token cookie in the browser, then steps 3, 4 and 5 are omitted.

For each request, a short term session token is created by the Authority Server which is used to perform the authentication transfer to the DSP.

The AAP stores both tokens in browser session cookies limited to the Authentication Domain, in this case Athens.

The AAP checks the DSP return URL against its list of registered DSP URLS, and if valid refers the user’s browser back to the return URL with an encoded packet containing the session token.

The DSP server must then check the session token with Athens to ensure that the token was issued by Athens, and may request attributes related to the user and his organisation. Please refer to the Athens attribute schema document for more details.

The session token is only valid for a short period after the user has been referred to the DSP, and so the DSP software must maintain a record of the user’s authentication using mechanisms such as HTTP cookie sessions. The Athensreference implementations include such a mechanism.

As an additional security measure the DSP may also decide to keep a record of session tokens that are still valid to avoid an attacker from re-playing an existing session token.

The DSP then performs its own authorisation before allowing the user entry into the resource. This may be based on Athens attributes and may also include resource specific authorisation requirements, for instance resource registration.