Overview of SSO

Crowd provides single sign-on (SSO) across a number of applications. This means that users can log in just once, then access the applications without having to log in to each one individually.

In Crowd Server the SSO functionality is available for applications within a single domain, such as Jira, Confluence and others. Crowd Data Center offers SSO 2.0 that is multi-domain.

In Crowd Server single domain SSO you can also extend SSO to beyond-the-firewall applications using CrowdID for OpenID and Crowd's Google Apps connector.

This page gives an overview of Crowd's Server single domain SSO capabilities, plus links to detailed information on configuring Crowd and the applications concerned.

If you are looking for multi-domain SSO please go to Crowd SSO 2.0

SSO within a Single Domain

The core Crowd functionality supports SSO across applications within a single domain, such as *.mydomain.com. Crowd uses a browser cookie to manage SSO. Because your browser limits cookie access to hosts in the same domain, this means that all applications participating in SSO must be in the same domain.

Example 1: If you wish to have single sign-on (SSO) support for *.mydomain.com, you will need to configure the SSO domain in Crowd as mydomain.com. All your Crowd-connected applications must be in the same domain. For example:

Example 2: If you wish to have single sign-on (SSO) support for mydomain.com/*, you will need to configure the SSO domain in Crowd as mydomain.com. All your Crowd-connected applications must be in the same domain. For example:

You can find information the comparison of host name strings in RFC 6265 (section 5).

You can configure the SSO domain via the Crowd Administration Console, as described in the documentation.

How It Works

The diagram below gives a conceptual overview of an HTTP request passing through an SSO filter and moving directly through the application business logic to create the response. (Click the link below the diagram to see a larger version.)

The diagram shows the 'happy path' only, assuming that:

• The user has already logged in to an application that is configured to participate in SSO. If the user has already logged in to one application, they will not need to log in again when accessing another application in the same domain.
• The request passes all authentication and authorization checks.

The diagram illustrates the following steps:

• Step 1: The HTTP request with an SSO cookie.
  1. 1. The user has already logged in to an application that is part of the SSO environment.
     2. The user accesses a new application within the SSO environment, or performs some other action on the website.
     3. The browser creates an HTTP request, bundles all the cookies for the domain and sends the request to the web application. This includes the SSO cookie, since the user has already logged in.
     4. The request is trapped by the SSO filter in the web application's security framework. This filter may be provided by Atlassian Seraph, by Spring Security, by another framework or via custom code.
     5. (If the user has not logged in, the filter re-directs the user to the login screen at this point. But we're assuming the user has logged in.)
     6. The Crowd authenticator finds the SSO cookie, extracts the SSO token and passes the token to Crowd. The Crowd authenticator is a plugin to the security framework (Atlassian Seraph, Spring Security, or others).
• Step 2: Validation of the SSO token.
  1. 1. Crowd validates the session token. If another application in the same domain has already authenticated the user, Crowd will validate the existing authentication.
     2. If the session has expired, Crowd re-directs the user to the login screen and re-authenticates the user.
     3. Crowd checks that the user is authorized to access the application.
     4. If the user does not have the required permissions, Crowd re-directs the user to the login screen.
     5. Once validation is successful, Crowd passes the validated token back to the application's SSO filter.
        If the session is still valid, the user will not need to log in again even if accessing a different application. The authentication and authorization will be transparent to the user.
• Step 3: Processing of the HTTP request.
  1. 1. The application's SSO filter passes the request to the business logic handler. (In a Java application, this is the servlet.)
     2. The business logic handler processes the request and builds the response.
• Step 4: The HTTP response.
  1. 1. The application sends the response back to the browser.

Here is a an overview of servlet filters from Oracle and a useful tutorial from O'Reilly.

The SSO filter may be provided by a security framework or by custom code as follows:

Configuring Crowd for SSO

Below are the configuration settings which affect SSO:

Configuring the Applications for SSO

When integrating an application with Crowd, you will configure the application to use Crowd as a centralized authentication repository. For most applications, but not all, you can also choose to configure SSO. This is described in detail for each application:

• Integrating Crowd with Atlassian Bamboo
• Integrating Crowd with Atlassian Confluence
• Integrating Crowd with Atlassian CrowdID
• Integrating Crowd with Atlassian Crucible
• Integrating Crowd with Atlassian FishEye
• Integrating Crowd with Atlassian Jira
• Integrating Crowd with Atlassian Bitbucket
• Integrating Crowd with Acegi Security
• Integrating Crowd with Jive Forums
• Integrating Crowd with Spring Security
• Integrating Crowd with a Custom Application

Troubleshooting SSO

See Troubleshooting SSO with Crowd.

SSO Beyond the Firewall

Crowd allows you to extend SSO to beyond-the-firewall applications using CrowdID and Crowd's Google Apps connector.

Using CrowdID as an OpenID Provider

Crowd allows you to host an OpenID provider, called CrowdID, so that your users have a single point of authentication for all OpenID-enabled websites. Refer to the CrowdID Administration Guide and CrowdID User Guide.

OpenID is an open, free protocol which allows a user to have a single identifier for logging in to any OpenID-enabled website. The website will communicate with a specific OpenID provider (in this case, your CrowdID server) when attempting to verify the user's login. For example, if your team uses 37signals' CRM tool Highrize, using Crowd's OpenID provider means you can get SSO between Highrize and your behind-the-firewall applications for all your team.

Using SSO with Google Apps

Crowd offers SSO with Google Apps via the Google Apps connector shipped with your Crowd installation. This means that your users can log in just once and then move between Google Apps and other applications like Jira, Confluence, etc.