Updated (May 31, 2021): The behavior is enabled by default since Chrome 84.
Updated (April 3, 2020): Chrome is Temporarily rolling back SameSite Cookie Changes
Updated (June 12, 2020): Added information about the fixed versions of the SAML 2.0 connector.
With the release of Chrome 80 in February, the default behavior of how Chrome is treating cookies without an explicit SameSite attribute is changing: these cookies will be handled as
SameSite=Lax which means that such cookies will only be sent from the browser to the server in first-party or same-site contexts and won't be sent with cross-site requests.
The current roll-out plan according to https://www.chromium.org/updates/same-site is the following:
February 4, 2020: Chrome 80 Stable released. The enablement of the SameSite-by-default and SameSite=None-requires-Secure enforcement will not be included in this initial Chrome 80 stable rollout. Please see the next item for more detailed information on the when SameSite enforcement will be enabled for Chrome 80 stable.
February, 2020: Enforcement rollout for Chrome 80 Stable: The SameSite-by-default and SameSite=None-requires-Secure behaviors will begin rolling out to Chrome 80 Stable for an initial limited population starting the week of February 17, 2020, excluding the US President’s Day holiday on Monday. We will be closely monitoring and evaluating ecosystem impact from this initial limited phase through gradually increasing rollouts.
End-users can disable these settings via
chrome://flags/#cookies-without-same-site-must-be-secure (available as of Chrome 76).
To learn more about the SameSite cookie settings and the changes in the default behavior please refer to the Additional Information section below.
Impact on Liferay's SAML Integration
Note: Liferay instances configured as Service Providers (SP) and connecting to a non-Liferay Identity Provider (IdP) should consult with their provider to clarify if they are affected.
For every browser session, the first SP initiated SSO request will continue to work, but require users to log into the Liferay SAML IdP - even if they have an already authenticated session on the IdP. This behavior is identical to when you configure the SAML plugin to Force Re-Authentication. The second SP initiated SSO request will require users to relaunch the browser beforehand in order to succeed.
SAML Single Logout does not work correctly with a Liferay SAML IdP. The flow is terminated on the IdP with a prompt stating you are signed in. From this point it can become difficult to log out from the SP without deleting all related cookie on the SP.
Redirection back to the page you were on when you made an SSO request on the SP works correctly. This is because the redirection URL is propagated through a "state" URL parameter and not kept in the Liferay SP's guest session.
Your environment may be affected if it meets all of the following criteria:
- Liferay Portal 6.x EE and Liferay DXP 7.x deployments configured as SAML IdP using Liferay Connector to SAML 2.0, versions
- 5.0.0 for DXP 7.2
- 4.1.0 and below for DXP 7.1
- 3.1.1 and below for DXP 7.0
- 2.1.3 and below for Liferay Portal 6.2 EE
- 1.0.4 and below for Liferay Portal 6.1 EE GA2 and GA3
- Web sites connecting to a Liferay SAML IdP as Service Providers
- The Service Providers and the Identity Provider are running on different domains, for example:
- https://www.mydomain.com -> https://www.idp.otherdomain.com : Affected (cross-site)
- https://www.mydomain.com -> https://idp.mydomain.com : Not Affected (same-site)
- End-users using Google Chrome 80 or higher
Long Term Resolution
Liferay implemented a logic that controls the attribute of the SameSite cookies in LPS-108070.
- Liferay Connector to SAML 2.0 for DXP 7.0: 3.1.2+
- Liferay Connector to SAML 2.0 for DXP 7.1: 4.1.1+
- Liferay Connector to SAML 2.0 for DXP 7.2: 5.0.1+
(Updated on June 12, 2020.)
The previous version of the first-party / same-site cookie handling specification didn't define a means to explicitly declare that a cookie should support 3rd party contexts. This resulted in these browsers either completely rejecting cookies with
SameSite=None, or interpreting it as
SameSite=Strict. Essentially the opposite to historic cookie behavior! For example, see this Safari bug https://bugs.webkit.org/show_bug.cgi?id=198181
It is worth highlighting that in the case of Safari and browsers on iOS devices, an OS (OSX / iOS) upgrade is needed in order to correctly handle
SameSite=None. This, of course, requires a lot more investment than simply upgrading a browser, making it more likely that incompatible versions remain in use.
The good news is that these same browser/versions continue to support the old cookie behavior. So this provides an opportunity to fix the incompatibility with
SameSite=None through setting a 2nd cookie without any SameSite attribute and falling back to reading this cookie when the primary cookie is not sent by the browser.
It is possible to rewrite the Set-Cookie response headers and add
SameSite=None; Secure at the Web Server level, like for example, using the Apache2 Headers mod:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=None
Note: this is just an example.
- Chromium Blog: Temporarily rolling back SameSite Cookie Changes (April 3, 2020)
- Chromium Blog: SameSite Cookie Changes in February 2020: What You Need to Know
- Chromium Blog: Developers: Get Ready for New SameSite=None; Secure Cookie Settings
- web.dev: SameSite cookies explained
- The Chromium Projects: SameSite Updates
- The Chromium Projects: SameSite=None: Known Incompatible Clients