- 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
- Request Security Considerations
- 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
Enabling Restricted Tokens for CDSSO Session Cookies
When the session cookie is a cross-domain single-sign on (CDSSO) cookie, meaning that it is valid across several domains, the damage a malicious user can cause is increased.
A malicious user who steals a CDSSO cookie can potentially use it to access any realms that session has logged into, which may span multiple domains. For example, a token stolen from
myapp.example.com could be used to access
payroll.internal.com or any other protected domain in the same realm. Cookie hijacking protection restricts cookies to the fully qualified domain name (FQDN) of the host where they are issued, such as
server-with-agent.example.com, using CDSSO to handle authentication and authorization.
For CDSSO with cookie hijacking protection, when a client successfully authenticates, AM issues the master SSO token cookie for its FQDN. AM issues restricted token cookies for the other FQDNs where the web or Java agents reside. The client ends up with cookies having different session identifiers for different FQDNs, and the AM server stores the correlation between the master SSO token and restricted tokens, such that the client only has one master session internally in AM.
To protect against cookie hijacking, you restrict the AM server domain to the server where AM runs. This sets the domain of the SSO token cookie to the host running the AM server that issued the token. You also enable use of a unique SSO token cookie. For your Java agents, you enable use of the unique SSO token cookie in the agent configuration.
Client-based sessions do not support restricted tokens. Therefore, Web Agents and Java Agents configured in a realm configured for client-based sessions are not protected against cookie hijacking. ForgeRock recommends using web or Java agents with CTS-based sessions.
In the AM console, navigate to Configure > Global Services > Platform.
Remove all domains from the Cookies Domains list.
Save your work.
Navigate to Configure > Server Defaults > Advanced.
com.sun.identity.enableUniqueSSOTokenCookieadvanced property to
Save your work.
Restart AM or the container in which it runs for the configuration changes to take effect.