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

Skip to end of metadata
Go to start of metadata
The SSO domain is used when setting HTTP authentication cookies in a user's browser. If this attribute is not correct, single sign-on (SSO) will not work when the user switches between applications.

On this page:

Overview

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).

(info) When developing on your local machine, you should set the domain to localhost.

Setting the SSO Domain

To specify the domain:

  1. Log in to the Crowd Administration Console.
  2. Click the 'Administration' tab in the top navigation bar.
  3. The 'General Options' screen will appear. Type the new domain into the 'SSO Domain' field.
  4. Click the 'Update' button.


Screenshot: 'General Options'

Setting the SSO Domain when Crowd is behind a Proxy Server

If Crowd is being run behind a proxy server, before setting the SSO domain value, make sure that the domain specified in the proxy (that is currently being used to access the Crowd console) was specified in the Tomcat connector proxyName attribute. Example:

File: Apache-Tomcat/conf/server.xml

<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false"
maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25"
port="8095" redirectPort="8443" useBodyEncodingForURI="true"
proxyName="mycompany.com" />

Notes

  • Avoiding problems with old cookie versions. In order to avoid problems with hosts or domains defined in old cookie versions, after setting the SSO Domain in Crowd, log out of Crowd and the integrated applications and delete all the web browser cookies.
  • SSO domain. The 'SSO Domain' field will accept only values based on the domain that is used to access the Crowd console. For instance, if you are using 'www.mycrowd.com/crowd/console' to access the console in the web browser, this field will accept the following values:
    • Empty
    • mycrowd.com
    • .mycrowd.com

      If you enter any other value, Crowd will show an error message: The supplied domain is invalid.
  • IP addresses. SSO will not operate when sites are accessed using IP addresses rather than domain names. This is a limitation of the cookie technology implemented in web browsers.
RELATED TOPICS

Overview of SSO
Configuring Trusted Proxy Servers

Crowd Documentation

12 Comments

  1. Anonymous

    Considering that the most likely (reverse) proxying using Apache Server is going to involve AJP1.3, shouldn't the proxyName Connector example use the AJP connector instead of the HTTP connector?

  2. Anonymous

    Can we have more than one domain for SSO ? So we have domain .companyA.com and .companyB.com  and .companyC.com and we want to manage users from all these companies to be able to use SSO for JIRA and Confluence.

    Thanks, Gaj

    1. Anonymous

      Forgot to add - All our applications are in one domain called .companyA.com but our users are in several different domains that are available on an LDAP.

    2. A similar problem, we do have an intranet domain which is different from the one used for public sites. Also, we have additional domains, due to the acquisition of other companies.

      How we are supposed to configure this? The documentation says nothing about this.

      1. Anonymous

        As a solution Crowd should set multiple cookies in users browser, each one for each domain.

        For example

        name=token    value=123     domain=.example1.com

        name=token    value=123     domain=.example2.com

        1. I'm seeing that our company would like to implement this as well so I created a feature request for Crowd: CWD-3524 - Allow multiple domains for SSO in Crowd Resolved

  3. In the next version of Crowd, can SSO please be turned on by default? Or at the very least, can SSO be turned on without having to restart the apps in question?

  4. Anonymous

    My main problem with crowd is it's a single point of failure. If I were to configure all of my applications in crowd I would end up with a single point of failure causing company wide outages. IF each application could failover to another authentication mechanism(without having it syncing away in the background.... and if crowd could support multiple LDAP servers with failover, and if I could configure a single directory for all applications, so I don't end up with sync errors on one app taking down another...

    As you can see, incredibly flawed... I think it needs a redesign it's p2p between atlassian products, based on app links.

    1. Anonymous

      Can't you just add in clustered sessions and drop multiple instances behind a load balancer such as an F5?

  5. FYI this is me...

     

  6. Anonymous

    We have a customer who is thinking of using Office365. Their user directory (and domain) will be Azure Active Directory. Any SSO possible then?

    1. We haven't verified if the integration works - feel free to vote up  CWD-3607 - Provide support for Windows Azure Active Directory Open