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. The SSO functionality is available for applications within a single domain, such as JIRA, Confluence and others. 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 SSO capabilities, plus links to detailed information on configuring Crowd and the applications concerned.
Looking for a multi-domain SSO solution?
Look no more! Crowd 3.4 with it's Crowd SSO 2.0 feature offers one solution for Server, Data Center, and Cloud applications and setting it up takes only minutes.
Are you are ready for the change? See 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 — including the full stop ('.') at the beginning. All your Crowd-connected applications must be in the same domain. For example:
FishEye in different domain
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:
FishEye in different domain
You can find information the comparison of host name strings in RFC 2965 (pages 2 and 3).
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.
- The user has already logged in to an application that is part of the SSO environment.
- The user accesses a new application within the SSO environment, or performs some other action on the website.
- 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.
- 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.
- (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.)
- 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.
- Crowd validates the session token. If another application in the same domain has already authenticated the user, Crowd will validate the existing authentication.
- If the session has expired, Crowd re-directs the user to the login screen and re-authenticates the user.
- Crowd checks that the user is authorized to access the application.
- If the user does not have the required permissions, Crowd re-directs the user to the login screen.
- 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.
- The application's SSO filter passes the request to the business logic handler. (In a Java application, this is the servlet.)
- The business logic handler processes the request and builds the response.
- Step 4: The HTTP response.
- The application sends the response back to the browser.
The SSO filter may be provided by a security framework or by custom code as follows:
Security Framework or Custom Code
Framework: Atlassian Seraph
Most of the Atlassian applications use Seraph. The Crowd documentation tells you how to integrate SSO into Confluence, JIRA, Bamboo, etc. If you are integrating a custom application with Crowd, you may also decide to use Seraph as your security framework.
Framework: Spring Security
You may have a web application that uses the Spring Security framework and that you are now integrating with Crowd. The Crowd documentation tells you how to integrate SSO into a Spring Security-based application.
Framework: Acegi Security (old)
You may have a web application that uses the Acegi Security framework and that you are now integrating with Crowd. The Crowd documentation tells you how to integrate SSO into an Acegi-based application.
Crowd provides a custom integration with FishEye and/or Crucible, including SSO. See the Crowd documentation.
Crowd API for your custom application
When integrating your own web application with Crowd, you can use the Crowd API to implement SSO.
Configuring Crowd for SSO
Below are the configuration settings which affect SSO:
Set your SSO domain
Set the domain via the Crowd Administration Console, as described in the documentation.
Optional: Configure Trusted Proxy Servers
Configure Crowd to trust a proxy's IP address, if you are running applications behind one or more proxy servers. See the documentation.
Optional: Enforce a secure connection, such as SSL, for all SSO requests
You can specify that the 'secure' flag is set on the SSO cookie, as described in the documentation.
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 Server
- Integrating Crowd with Acegi Security
- Integrating Crowd with Apache
- Integrating Crowd with Jive Forums
- Integrating Crowd with Spring Security
- Integrating Crowd with Subversion
- Integrating Crowd with a Custom Application
- Integrating Crowd with Atlassian HipChat
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.