Documentation for Crowd 2.7. Documentation for earlier versions of Crowd is available too.

Skip to end of metadata
Go to start of metadata

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.

On this page:

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:

Crowd

crowd.mydomain.com

(tick)

JIRA

jira.mydomain.com

(tick)

Confluence

confluence.mydomain.com

(tick)

FishEye

fisheye.mydomain.com

(tick)

FishEye in different domain

fisheye.example.com

(error)

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:

Crowd

mydomain.com/crowd

(tick)

JIRA

mydomain.com/jira

(tick)

Confluence

mydomain.com/confluence

(tick)

FishEye

mydomain.com/fisheye

(tick)

FishEye in different domain

example.com/fisheye

(error)

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 authorisation checks.

Gliffy Zoom Zoom

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 authorised 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.
      (info) If the session is still valid, the user will not need to log in again even if accessing a different application. The authentication and authorisation 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.

(info) Here is a an overview of servlet filters from Sun and a useful tutorial from O'Reilly.

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

Security Framework or Custom Code

Comments

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.
A point of interest: Crowd uses the Spring Security framework, and so does the Crowd 'demo' 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.
Note that Acegi Security is an earlier version of Spring Security.

Custom authentication for Atlassian FishEye and Crucible

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.

  • We recommend that you use the Crowd REST APIs for long-term compatibility.
  • If you have a Java application, you can use the Java Integration Libraries shipped with Crowd, but please be aware that they may change between releases. You may need to re-compile your source and possibly change a package name.
  • There are a number of third-party language bindings and application connectors developed by Crowd users. You can see them in the Atlassian Marketplace.

Configuring Crowd for SSO

Below are the configuration settings which affect SSO:

Short Description

More Information

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.
(warning) Unsecured connections will be rejected, including the Crowd Administration Console if not accessed via SSL.

Configuring the Applications for SSO

When integrating an application with Crowd, you will configure the application to use Crowd as a centralised authentication repository. For most applications, but not all, you can also choose to configure SSO. This is described in detail for each 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 Highrise, using Crowd's OpenID provider means you can get SSO between Highrise 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.

RELATED TOPICS

Managing Applications
System Administration
Crowd Documentation

  • No labels

0 Comments