- General Security Considerations
- Securing Network Communication
- Preventing Insecure HTTP and LDAP Connections
- Configuring AM Behind a Reverse Proxy
- Configuring CORS Support
- Configuring the Cookie Domain
- Cross-Site Request Forgery (CSRF) Protection
- Securing Administrative Access
- Securing Realms
- Configuring Secrets, Certificates, and Keys
- Features in AM That Use Keys
- Managing the AM Keystore
- Managing Key Aliases and Passwords
- Configuring Secret Stores
- Mapping and Rotating Secrets
- Changing Default Key Aliases
- Securing the Session Cookie
- Additional Cookie Security Considerations
- Securing Sessions
- Understanding Session Termination
- Configuring Account Lockout
- Configuring Session Quotas
- Configuring Client-Based Session Security
- Configuring Authentication Session Whitelisting
- Protecting Applications
- Setting Up Audit Logging
- About the Audit Logging Service
- Implementing the Audit Logging Service
- Configuring Audit Logging
- Configuring Audit Event Handlers
- Configuring the Trust Transaction Header System Property
- Implementing the Classic Logging Service
- Audit Logging Reference
- Customizing CTS-Based Session Quota Exhaustion Actions
Configuring 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
example.com so AM can communicate with any host in the sub-domain.
Log in to the AM console as an administrator user, for example,
Navigate 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. 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 "Enabling Restricted Tokens for CDSSO Session Cookies".
Do not configure a top-level domain as your cookie domain; 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 .
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 console under Configure > Server Defaults > Advanced.
Save your changes.
Restart AM or the container where it runs.
 For a list of effective top-level domains, see https://publicsuffix.org/list/effective_tld_names.dat.