Since February 2020, Google® has been rolling out Chrome releases (starting with Chrome 80) that treat all cookies that do not explicitly set the SameSite attribute as though they have been set to SameSite=Lax. Additionally, cookies with the SameSite=None attribute must also be Secure else they will be rejected. This enhancement is part of their ongoing changes to how Chrome handles cookies, with particular focus on the SameSite attribute. Changes were introduced in Chrome 76 (August 2019) to handle cookies with the SameSite attribute. Initially, any cookies that did not set the SameSite attribute were treated as though they were set to SameSite=None to ensure no changes in behavior.
Other browsers have introduced similar changes or are in the process of rolling out these changes. In particular, Edge has implemented these changes in version 86 (October 2020), Firefox has been testing SameSite=Lax on its beta users and will roll out to everyone at a later date and Safari blocks all cross-site cookies.
The following links provide more background on these changes and timescales:
- Edge: Version 86.0.622.38: October 9
- Firefox: Changes to SameSite Cookie Behavior – A Call to Action for Web Developers
- Safari: Full Third-Party Cookie Blocking and More
- SameSite Cookies - Are you Ready?
The SameSite=Lax attribute prevents browsers from sending cookies in cross-site requests (where the registrable domain differs), unless they are top-level navigation requests that use a safe HTTP method (defined as GET, HEAD, OPTIONS or TRACE). Cross-origin requests (for example, a request from ui.example.com to api.example.com) are allowed because the registrable domain is the same. In reality, this means you are unlikely to be affected by this change unless you have genuine multi-domain installs or are using federation.
The following list provides some features (but not all) that are expected to be affected by these changes in pre-AM 18.104.22.168:
- SAML2 Single Logout (SLO) using the HTTP POST binding. AM will fail to see the session cookie on the logout request, which will cause logout to fail.
- Some uses of the SAML2 POST binding and the OpenID Connect Form Post response mode may be impacted. In particular, the common pattern of setting the
stateparameter as a cookie at the client before starting an OIDC flow may no longer work if the Form Post response mode is used.
- Any cross-site use of AM's REST APIs that has been configured with Access-Control-Allow-Credentials to enable cookie support. SameSite effectively completely disables this usage of CORS.
- The use of AM embedded in an iframe. For example, when using the OIDC checkSession endpoint or doing a "silent renew" pattern such as loading the authorization endpoint in an iframe with prompt=none to check if the user is still logged in.
You can upgrade to AM 22.214.171.124 and later to ensure AM continues to work as before. See AM fixed versions and support patches for further information.
The expected impacts depend on the version of IG, and whether you are using standalone mode or web container mode:
- Standalone mode: IG maintains the sameSite attribute setting for any cookies that arrive at IG.
As of IG 7.1.2, you can explicitly set the sameSite attribute for the session cookie to manage the circumstances in which a session cookie is sent to the server. See What’s New in IG 7.1.2 for further information.
- Web container mode: IG strips the sameSite attribute in pre-IG 6.5.2 versions.
You can upgrade to IG 6.5.2 or later to ensure IG maintains the sameSite attribute setting for any cookies that arrive at IG. See Improvements in IG 6.5.2 for further information.
AM 126.96.36.199 and later add a new filter that sets the SameSite=None attribute for all secure AM cookies on compatible browsers. You can download this from Backstage.
A SameSite Cookie Support Patch is available for the following versions, which adds the new filter:
- AM 188.8.131.52 (same patch will work for all 6.5.2.x versions)
- AM 6.5.1
- AM 184.108.40.206 (same patch will work for all 6.0.0.x versions)
You can download these patch bundles from Backstage. See How do I install an AM patch (All versions) supplied by ForgeRock support? for further information on installing these patches. Since the web.xml file is being updated, you may need to delete the web container working files and restart AM. For example, if you deploy on Apache Tomcat™, you may need to delete the /path/to/tomcat/work/Catalina/localhost/am/ directory.
The recommendation is to upgrade to a fixed version or deploy the relevant patches at the earliest opportunity to prevent AM features being impacted.
The new filter included in the fixed AM versions and support patches sets the SameSite=None attribute for all Secure cookies unless:
- The cookie is not set by AM. Cookies set by custom code (for example, cookies containing a nonce or state value when performing an OIDC response_mode=form_post flow) must be manually updated. This can be automated using IG as indicated below.
- The user is using an incompatible browser such as Safari on Mac® OS 10.14 or iOS® 12 (which incorrectly treats the SameSite=None attribute as SameSite=Strict). This issue has been fixed in newer versions of Mac OS and iOS.
- The filter includes a list of User-Agents for which the filter is disabled based on Google's list (SameSite=None: Known Incompatible Clients). However, you can customize it if required by updating the filter definition for the DisableSameSiteCookiesFilter in the web.xml file (located in the /path/to/tomcat/webapps/am/WEB-INF directory).
Before you upgrade or install this patch, you must be aware of the following:
- If your cookies are not currently secure, you
enable secure cookies (
com.iplanet.am.cookie.secure) before upgrading or installing this patch to ensure this filter sets the SameSite attribute correctly. See Cookie for further information.
- The fixed versions and patches make changes to the web.xml file; if you have customized this, you will need to re-add your changes once you have upgraded or applied the patch.
Configuring load balancers, external gateways and reverse proxies is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Deployment Support Services.
If you are using IG 6.5.2 or later, you can configure cookies originating from IG (the cross-domain SSO token cookie and JWT session cookie) with the sameSite attribute. The sameSite attribute is available in the CrossDomainSingleSignOnFilter and JwtSession to manage the circumstances in which a cookie is sent to the server. See CrossDomainSingleSignOnFilter and JwtSession for further information.