Crowd 2.1 : Domain
This page last changed on Nov 23, 2010 by smaddox.
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: OverviewThe 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:
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 2965 (pages 2 and 3).
Setting the SSO DomainTo specify the domain,
Screenshot: 'General Options'
Setting the SSO Domain when Crowd is behind a Proxy ServerIf 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" Notes
RELATED TOPICSOverview of SSO |
![]() |
Document generated by Confluence on Nov 30, 2010 23:53 |