Change the cookie domain
Configure AM’s cookie domain to ensure only users and entities from trusted domains can be authenticated.
By default, the AM installer sets the cookie domain based on the fully qualified hostname of the server
on which it installs AM, such as
After installation, you may want to change the cookie domain to
so AM can communicate with any host in the sub-domain.
In the AM admin UI, go to Configure > Global Services > Platform > Cookie Domain.
In the Cookie Domain field, set the list of domains into which AM should write cookies. Consider the following points:
Configure as many cookie domains as your environment requires. For example, for the realms configured with DNS aliases. (For more information, see Realms.) Browsers ignore any cookies that do not match the current domain to ensure the correct one is used.
If you do not specify any cookie domain, AM uses the fully qualified name of the server, which implies that a host cookie is set rather than a domain cookie.
When configuring AM for Cross-Domain Single Sign-On (CDSSO), you must protect your AM deployment against cookie hijacking by setting a host cookie rather than a domain cookie. For more information, see Restrict tokens for CDSSO session cookies.
Do not configure a top-level domain as your cookie domain because browsers will reject them. Top-level domains are browser-specific. For example, Firefox considers special domains like Amazon’s web service (for example,
ap-southeast-2.compute.amazonaws.com) to be a top-level domain. (For a list of effective top-level domains, see https://publicsuffix.org/list/effective_tld_names.dat.)
Do not configure the cookie domain such that it starts with a dot (.) character. For example, configure
If you are using Wildfly as the AM web container with multiple cookie domains, you must set the advanced server property,
Set this property in the AM admin UI, under Configure > Server Defaults > Advanced.
Save your changes.
Restart AM or the container where it runs.