Before you install
Before you install this patch, you must be aware of the following:
- If your cookies are not currently secure, you must enable secure cookies (com.iplanet.am.cookie.secure) before installing this patch to ensure this filter sets the SameSite attribute correctly. See Reference › Cookie for further information.
- This patch makes changes to the web.xml file; if you have customized this, you will need to re-add your changes once you have applied the patch.
This article only applies to the upcoming changes in the Chrome™ browser. Other browsers (Safari®, Firefox®, Internet Explorer® and Microsoft Edge) have not implemented SameSite cookie support, and are therefore unaffected. However, certain older browsers are known to be incompatible with the SameSite=None attribute.
Please see the Filter Details subsection for further information on the incompatible User-Agents, and how to selectively filter and disable SameSite attributes for those browsers.
Google® have announced that Chrome 80 (due for release in February 2020) will 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 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.
The following links provide more background on these changes and timescales:
- Chromium Blog: Improving privacy and security on the web
- The Chromium Projects: SameSite Updates
- Reject insecure SameSite=None cookies
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.
Expected impacts in AM
The following list provides some features (but not all) that are expected to be affected by these changes:
- 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 "state" parameter 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.
Expected impacts in IG
IG strips the SameSite attribute in pre-IG 6.5.2 versions. You can upgrade to IG 6.5.2 to ensure IG maintains the SameSite attribute setting for any cookies that arrive at IG. See Release Notes › Improvements in IG 6.5.2 for further information.
AM fixed versions and support patches
AM 5.5.2, and AM 184.108.40.206 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 220.127.116.11 (same patch will work for all 6.5.2.x versions)
- AM 6.5.1
- AM 18.104.22.168 (same patch will work for all 6.0.0.x versions)
- AM 5.5.1
- AM 5.1.1
You can obtain these patch bundles from BackStage. See How do I install an AM/OpenAM patch (All versions) supplied by ForgeRock support? for further information on installing these patches.
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 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/openam/WEB-INF directory).
A patch bundle is not available for OpenAM 13.x per the ForgeRock End of Service Life (EOSL) policy.
If you encounter any issues as a result of how Chrome handles SameSite cookies, the recommended workarounds are:
- Upgrade to a fixed version of AM (AM 5.5.2; AM 22.214.171.124 and later).
- Upgrade to a version of AM that has a patch (AM 5.1.1, AM 5.5.1, AM 6.0.0.x, AM 6.5.1 or AM 6.5.2.x) and install the patch.
- Use a binding other than HTTP POST for SLO.
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 use the sameSite property in CrossDomainSingleSignOnFilter and JwtSession to manage the circumstances in which a cookie is sent to the server. See Configuration Reference › CrossDomainSingleSignOnFilter and Configuration Reference › JwtSession for further information.