1. Liferay Help Center
  2. Base de Conhecimento
  3. Reference

Impact of Google Chrome 80 and changes in the default behavior of the SameSite cookie setting on SAML

Avatar

Tibor Lipusz

  • Atualizado

Issue

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/#same-site-by-default-cookies and 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.

Affected Environments

Your environment may be affected if it meets all of the following criteria:

  1. 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
  2. Web sites connecting to a Liferay SAML IdP as Service Providers
  3. The Service Providers and the Identity Provider are running on different domains, for example:
  4. End-users using Google Chrome 80 or higher

Resolution

Long Term Resolution

Liferay implemented a logic that controls the attribute of the SameSite cookies in LPS-108070.

Fixed Versions

  • 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.)

More Information

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.

 

Alternative Solution

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.

Additional Information

Este artigo foi útil?
Utilizadores que acharam útil: 0 de 0