Restrict 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
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,
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-side sessions do not support restricted tokens. Therefore, web agents and Java agents in a realm configured for client-side sessions are not protected against cookie hijacking. ForgeRock recommends using web or Java agents with server-side sessions.
In the AM admin UI, go to Configure > Global Services > Platform.
Remove all domains from the Cookies Domains list.
Click Save Changes.
Go to Configure > Server Defaults > Advanced.
com.sun.identity.enableUniqueSSOTokenCookieadvanced property to
Click Save Changes.
Restart AM or the container in which it runs for the configuration changes to take effect.