Browser changes to SameSite cookie handling

Problem

Chrome 80 will be implementing a SameSite policy such that any cookie not explicitly set with a SameSite value will be set to SameSite=Lax.

Full technical details of the SameSite attribute are available in the following RFC:https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7

Symptom

Symptoms will vary depending on the use of the cookie. For example, SP initiated logins that use an IDP on a different domain which has not set SameSite=None; Secure on their session cookie will have to constantly authenticate at the IDP because the session cookie will not be sent. Other flows which require a cookie will unexpectedly fail.

Cause

Google has announced that Chrome version 80 and later will change the defaults for cross-site HTTP Cookies. Other browser vendors are anticipated to make the same change in the near future. More information is available in the announcement from the Chromium project here: https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

Diagnosing the Problem

Given a failure to produce an expected response, validate that all of the following statements are true:

• The request originates from a browser, not a non-browser HTTP client.
• The enterprise application responsible for responding is protected by WebSEAL and depends on session management, affinity, or its own application-specific HTTP cookie.
• The cookie in question was unexpectedly not received within the HTTP request.
• The request itself is not a "top-level navigation"; in other words, it is not the request that shows in the browser's address bar.

  • Take note of the domain used in the top-level navigation.

• The cookie in question was not accompanied by the SameSite attribute when it was originally transmitted with the Set-Cookie HTTP response header.
• The "site for cookies" in the URL of the failing request is different from the "site for cookies" in the top-level navigation.
  • The algorithm for determining "site for cookies" for a request is described in detail here: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03
  • A simplified explanation of "site for cookies" for a request URL is the rightmost portion of the hostname that was directly registered with some public registry, or the "effective top-level domain + 1". For example, all URLs ending in ".example.com" have the same "site for cookies".

  • In addition to traditional TLDs (like .com and .net) and eTLDs (like ".co.uk"), browsers also consider "public suffixes" that users register subdomains with, that such as github.io. This means the "site for cookies" for URL http://test.github.io/ is "test.github.io".

Resolving the Problem

WebSEAL can be configured to add attributes to cookies as the cookies are sent back to the client. This is achieved by adding entries to the [cookie-attributes] stanza. Some older browsers do not support the SameSite=None option and behave inconsistently when a cookie is received with this attribute. To help overcome this issue the SameSite=None attribute should only be added to cookies if the user-agent does not match one of these older browsers. A new user agent group, as defined in the [user-agent-groups] stanza, has been added to the default WebSEAL configuration file to group these older browsers. The group name is 'unsupported-same-site' and should be used when defining the [cookie-attributes] stanza. The settings which can be used for a federated SSO flow are as follows:

PD-S-SESSION = [-unsupported-same-site]SameSite=None; Secure
PD_STATEFUL* = [-unsupported-same-site]SameSite=None; Secure
AMWEBJCT*<isam>*JSESSIONID = [-unsupported-same-site]SameSite=None; Secure
AMWEBJCT*<isam>*https*<SAMESITE_FEDERATION>* = [-unsupported-same-site]SameSite=None; Secure

where <SAMESITE_FEDERATION> is the name of an ISAM Federation and <isam> is the name of the junction created when running the built-in federation configuration wizard.

Parent topic: Common Security Verify Access problems