Single Sign-on Security

Overview

Single Sign-on uses a custom protocol developed specifically for Drupal, though using generic concepts and security practices.

• User and session-related tables are shared and a shared secret is set up for HMAC purposes.
• It does not pass anything around but short-term tokens and URLs
• Nonces are used to prevent replay attacks
• The security responsibilities are split clearly between request ID, nonce and cookie.
• The authentication only takes effect when both the controller and the client agree on the validity of the request.
• It is impossible to have part of the request performed by an unsuspecting victim through CSRF and still pass validation.

Architecture

There are 3 components in the SSO package:

SSO Session handler

This is a drop-in replacement for Drupal's session.inc. Compared to the standard Drupal session handler there are three main changes:

• Sessions are stored and loaded for a particular domain. Sessions IDs are only valid on a single domain.
• Sessions can have master/slave relationships. A slave session stores its associated master session ID.
• Sessions can store a nonce that acts like a one-use ticket used to claim a previously set up session.

The included file session.inc.diff shows the changes made to Drupal's session handler.

SSO Controller module

This module is run on a single site. It sets up linked sessions for client sites and takes care of authentication of users. The site that runs this module is referred to as the controller.

SSO Client module

This module is run on all other sites in the SSO network. It delegates any local authentication tasks to the controller site, and sets up a linked session with the controller site on the first visit (both for anonymous and authenticated users). A site running this module is called a client.

Protocol

Most of the complicated logic relates to how authentication is performed on the client. Session handling on the controller is nearly unchanged from plain Drupal session handling.

See 'flow.pdf' for a schematic overview of the SSO protocol. When reading the diagram, please note:

• All data passed through the user-agent from site to site is signed using HMAC and verified on the other side. This is omitted from the diagram for simplicity.
• All session IDs on the diagram remain constant for readability. Whenever a Set-Cookie header is used, it should be interpreted as regenerating the session ID in question to prevent session fixation attacks.

Session Association / Linking

See Flow 1 in flow.pdf.

Sessions on client sites are linked to sessions on the controller site. This allows (de)-authentication effects to propagate between different sites. Linked sessions are set up both for anonymous and authenticated users.

When a user first visits a client site, a linked session is set up. First, the client site generates an association request to the controller, through the user agent.

In response, the controller sets up a linked session with the same credentials as the user agent's current session, and tags this newly created session with a nonce. It then returns this nonce to the user agent and redirects them to the client site, where the newly created session is claimed.

Once the session is claimed, its session ID is revealed to the user agent and the old session (containing the request ID) is destroyed.

Notes:

• The request ID ensures that the person doing the initial request to the controller is the same person doing the claiming of the session at the client. It is impossible to use CSRF to trick someone into a claiming a session they didn't request, because they don't have the matching request ID in their client session.
• The newly created session ID is never passed over the wire, and only revealed when claimed using the nonce. Once the nonce has been used, it is impossible to use it again.
• The 'origin' argument in the request is signed using HMAC and determines which domain the newly created session is valid for. Thus it is impossible to trick someone into a setting up a useful linked session and revealing the claim request to a third party site.

Session Authentication / Logging in

See Flow 2 in flow.pdf.

Though the client site may host a log in form, all log in requests are submitted to the controller site. Submissions from client sites carry an additional origin parameter, which identifies the source site.

The controller site performs a normal Drupal log in, escalating the uid of the user agent's local session. When the session is saved, the session handler detects the uid change and deletes all associated client sessions.

On their next visit to a client site (which can be immediately after the log in), the user agent will no longer have a valid session with the client, and will need to re-associate with the controller site. As the user agent is now a privileged user on the controller site, the newly linked up session will carry the same privileges.

Notes:

• It might seem easier to simply escalate the privileges of any linked up sessions, rather than deleting them and forcing the user agent to re-associate on the next visit. However, this would not allow us to regenerate their session IDs, because the controller would not be able to set updated cookies for the associated client sites. Without session ID regeneration, session fixation attacks may become possible.

Session De-authentication / Logging out

The log out process is extremely simple, because it merely involves deleting existing sessions, rather than setting new cookies. This means it can be performed both by the controller as well as any client site.

Whenever a session is destroyed that has master/slave relationship to other sessions, all related master/slave sessions are destroyed as well.

Evaluation

The SSO module is designed to provide the same level of security as normal Drupal sessions. This means that it is designed to be secure against CSRF attacks and session fixation attacks.

Like normal Drupal authentication, this protocol is vulnerable to a network layer man-in-the-middle attack. This can be mitigated by using SSL on the controller and client sites.

As a compromise, it is possible to use SSL only on the controller site to protect users' log-in credentials, while keeping some or all other sites unencrypted. In that case, security measures such as 'session.cookie_secure' must be set on the log-in site. The resulting system would allow MITM attackers hijack existing sessions with unsecured client sites, but they would not be able to use that session to access any other site, or talk to the controller directly, because each site requires its own unique cookie, and SSL cookies cannot be snooped.