Jira Issue

Introduction

The Same-site cookie atribute is a IETF draft written by Google Inc. [1][2]which, at its most strict, instructs the user-agent not to send (attach) a SameSite cookie during a cross site HTTP request. The principal aim of which is to help prevent forms of cross site request forgery that ‘ride’ ambient authority session cookies.

A cross site request is, abstractly (see appendix A for the draft algorithmic definition), one where the top level site (typically that shown in an address bar) changes during navigation.

There are three values for the same-site cookie attribute:

• Strict - Only attach cookies for ‘same-site’ requests.
• Lax - Send cookies for ‘same-site’ requests, along with ‘cross-site’ top level navigations using safe HTTP methods e.g. (GET HEAD OPTIONS TRACE).

• None - send cookies for all ‘same-site’ and ‘cross-site’ requests.

Chrome 76 and onwards contain a flag to enable the treatment of cookies without a SameSite attribute to be SameSite=Lax. This will become the default in Chrome 80 [4], which has an approximate release date of February 2020 - see the section below for an overview of browser support. The aim of this document is to test the affects of such change on the IdP. Our immediate concern is, if the session cookies used by the IdP (depending on configuration) e.g. JSESSIONID, or shib_idp_session, do not specify the SameSite attribute - and are therefore defaulted to SameSite=Lax - and are being used in a cross-site POST request from an SP to the IdP, will it break either the IdP and or single-sign-on as potentially the session cookies will not be sent.

Further work will investigate a Proof of Concept servlet filter for munging appropriate IdP session cookies in order to set their SameSite attribute to None - thus maintaining their current behaviour. This is only necessary because the Java Servlet Specification v3.0 or v4.0 does not cater for the SameSite attribute, and it can not be set through the Java Cookie API.

SameSite Browser Support

The table below shows same-site cookie attribute compatibility amongst desktop browsers (see [5] for a complete list including mobile variants). It also includes an attempt to determine current/future browser support for IETF draft 'Incrementally Better Cookies '[6]. That is, defaulting same-site unset cookies to SameSite=Lax, and requiring SameSite=None cookies to be sent over secure transport (HTTPS).

The table will be updated as and when information becomes available.

Testing

To test the affects of various SameSite settings, the following setup will be used:

• Chrome Canary 78.0.3885.0 (Official Build) canary (64-bit), with #same-site-by-default-cookies set to enabled. This is to mimic what will become the default behaviour in Chrome 80 onward.
• The IdP running in eclipse using the Java idp-testbed project.
  • Using idp-jetty-base with Jetty v9.3.
  • A new SAML2Controller InitSSO POST method/endpoint. This overwrites the destination URL with localhost, ignoring the baseURL of the servlet request.
• A modified hosts file, that points the hostname of shibtest.com to 127.0.0.1 (localhost)
  • The SAML2Controller can then be accessed on a different top-level site than the IdP - to mimic a cross site request.
• The standard IdP Password authentication flow.

Using Client Side Session Storage, allowing HTML local storage.

The IdP is configured here to use client side session storage with, importantly, idp.storage.htmlLocalStorage set too true. The table below shows the results of various tests using different SAML2.0 bindings or initiators. The shib_idp_session_ss is less relevant, and could use local storage if supported by the browser with similar same effect.

Of note, this does not test the affect of any SP cookies sent cross-site from the IdP.

** This is only the case if the Client Session Storage Service beans are removed from the shibboleth.ClientStorageServices list. Otherwise, the PopulateClientStorageLoadContext will load session information from the client using the client-storage-read view-state, which will then send the shib_idp_session cookie same-origin after that view-state has posted back to the IdP.

IMPORTANT:
It appears that current versions of Chrome are treating defaulted (SameSite not set) cookies as SameSite Lax + POST for a period of 2 minutes from when they are set, then SameSite Lax thereafter Issue 990439 - chromium - An open-source project to help move the web forward. - Monorail. Within this window, the the IdP will operate normally, as if there is no SameSite restriction. Otherwise, there are two general possibities:

1. All IdP session cookies which where set more than 2 minutes ago are treated as Lax. This then gives the same result as test 5 above, and the description in the section [SameSite Lax POST flow].
2. Different combinations of JSESSIONID, shib_idp_session or shib_idp_session_SS are inside or outside of the 2 minute window. This leads to different types of behaviour; most commonly, as JSESSIONID is nearly (always) set first, the following would be true
   1. JSESSIONID=Lax+POST, shib_idp_session=Lax, shib_idp_session_ss=Lax. The JSESSIONID is sent cross-site with the post request but the shib_idp_session and shib_idp_session_ss are not. The storage services can be pulled out of the given session referenced by the JESSIONID, and hence client-storage-read is not required to reload it. The flow continues without the POST-REDIRECT-GET cycle of a view-state, hence the shib_idp_session cookie is not sent and the previous authentication result can not be retrieved from the IdPSession. As a result, the username and password login view is presented - thus breaking SSO.

SameSite Lax, POST flow, with client side session storage and HTML local storage option enabled

The following outlines the network interactions with the IdP for a POST SAML SSO request. The user has previously authenticated using the standard Password flow, and in so doing obtained shib_idp_session and JSESSIONID cookies. The IdP is using client side session storage, either as a cookie or in HTML local storage.

SO = Same-origin request.
CS = Cross-site request.
sp/SAML2/InitSSO-CS/POST = is a new controller endpoint that overrides destination address with ‘localhost’ to mimic a cross-site request.

1. user-agent top-level site is https://shibtest.com:8443.
2. (SO)(GET) user-agent navigates to https://shibtest.com:8443/sp/SAML2/InitSSO-CS/POST. Which is a same-origin request to initate a SAML 2 AuthN Request.
3. BEGIN SAML AUTHENTICATION REQUEST ------
4. (CS)(POST) The shibtest.com sp/SAML2/InitSSO-CS/POST controller performs a cross-site POST SAML authentication request to the IdP at https://localhost:8443/idp/profile/SAML2/POST/SSO.
   1. SameSite is LAX, hence cookies for the localhost domain are NOT sent cross-site e.g. any existing JSESSIONID, shib_idp_session or if present shib_idp_session_ss cookies are not sent.
   2. The IdP processes the SAML request, is unable to load the client storage context as the JESSIONID was not sent, and the new one the container issues does not link to a session that already exists. Hence it goes in search of the session from HTML local storage (because it is enabled), and proceeds to the LocalStorageRead view-state, commits a redirect response (https://localhost:8443/idp/profile/SAML2/POST/SSO?execution=e1s1) to the user-agent, and issues a new JSESSIONID.
   3. Note, the user-agent still has a top-level site of https://shibtest.com:8443.

1. (CS)(GET) The user-agent responds to the redirect with a cross-site GET request to https://localhost:8443/idp/profile/SAML2/POST/SSO?execution=e1s1. Which then displays the client-storage-read.vm page.
   1. Webflow is using a POST-REDIRECT-GET strategy*. This cycle is happening cross-site, but the final GET request allows Lax SameSite cookies to be sent. Hence, the new JSESSIONID obtained in the inital POST-REDIRECT response is sent with the final GET request and the flow can resume. Note, the shib_idp_session cookie is sent with the final GET cross-site request but that is not strictly that important at this stage.
   2. From here any subsequent requests occur same-origin so cookies are always sent.

1. (SO)(POST) The user-agent then POSTS form data from the client-storage-read view back to the IdP. This is a same-origin request, and contains all required cookies and session information.
   1. The flow continues and the shib_idp_sesison cookie is used to find a previous IdPSession from the loaded (from cookie or local storage) shib_idp_session_ss storage record during the PopulateSessionContext action using the StorageBackedSessionManager.
   2. The ExtractActiveAuthenticationResults action then extracts the AuthenticationResult from the IdpSession and, providing certain criteria are satisfied, enables SSO.

[*][By default when a flow enters a view state, it executes a client-side redirect before rendering the view]

Using Client Side Session Storage and Disabling HTML Local Storage.

Here we test again, this time disabling the IdPs ability to use HTML local storage to store session information, instead only using cookies e.g. setting idp.storage.htmlLocalStorage to false.

Using Server Side Session Storage and Enabling/Disabling HTML Local Storage. 

Four different POST requests where again tested, this time using server side session storage. The hypothesis being, under the following conditions, SSO will break:

1. The IdP session cookies are treated as SameSite=Lax.
2. The entire SAML2 SSO flow on the IdP is completed from the initial cross-site POST request from the SP - because the client-storage-read view is not required as client side storage is not used.

Contradictory to the hypothesis, test 13 shows SSO working even though the initial cross-site POST request does not send any of the IdP session cookies. This occurs because of the configuration of the IdP, that is; even if server side session storage is configured in idp.properties (idp.session.StorageService), the client-storage-read view is still rendered provided the idp.storage.htmlLocalStorage property is set to true, and the list of shibboleth.ClientStorageServices still contains reference to the various client storage services e.g.

idp.properties:
	idp.storage.htmlLocalStorage = true

session-manager.xml:
	<util:list id="shibboleth.ClientStorageServices">
        	<ref bean="shibboleth.ClientSessionStorageService" />
       	 <ref bean="shibboleth.ClientPersistentStorageService" />
	</util:list>

Of note, the IdP is still storing session information on the server even if those properties/beans are enabled. 

As per XML documentation surrounding this list, If server side storage is used these bean references can be safely removed. However, If they are removed, or the idp.storage.htmlLocalStorage is set to false,  the results in test 14 are observed and SSO breaks. That is to say, if server side session storage is used AND IdP session cookies are treated as SameSite=Lax (defaulting in chrome 80), and EITHER those bean references are removed OR idp.storage.htmlLocalStorage is disabled, SSO will break. 

Test 15 shows what happens if the shib_idp_session cookie is set to SameSite=None. This enables SSO, even if the JSESSIONID is set to SameSite=Lax and is not sent in the initial cross-site request.

In conclusion, IdP deployers using server side session storage should not experience issues with SSO for defaulted SameSite=Lax IdP session cookies using the HTTP-POST SAML2 binding, providing they have not removed those bean references and the idp.storage.htmlLocalStorage is enabled. 

Conclusion

In conclusion, the IdP should continue to function when its cookies are being defaulted to SameSite=Lax by browsers (currently tested on Chrome 78-81 and Firefox 72 with the same-site default flags set). Typically, we have only seen the IdP itself break when the JSESSIONID is set to SameSite 'Strict', which should not happen apart from when explicitly trying to set SameSite=None with older versions of Safari on MacOS <=10.14 and all WebKit browsers on iOS <=12  (https://bugs.webkit.org/show_bug.cgi?id=198181). However with regards to achieving single-sign-on you may see degraded operation, and the following possibilities occur:

• [client-side-storage] - If htmlLocalStorage is set to false, HTTP-POST SSO will not work (show login page again) with defaulted SameSite=Lax IdP cookies.
• [client-side-storage] - If htmlLocalStorage is set to true, and bean references in shibboleth.ClientStorageServices are left as they are, HTTP-POST SSO will work with defaulted SameSite=Lax
• [server-side-storage] - If htmlLocalStorage is set to true, and bean references in shibboleth.ClientStorageServices are left as they are, HTTP-POST SSO will work with defaulted SameSite=Lax.
• [server-side-storage] - If either htmlLocalStorage is set to false, or the bean references in shibboleth.ClientStorageServices are commented out, HTTP-POST SSO will not work (show login page again) with defaulted SameSite=Lax.

Therefore to try and guarantee SSO on existing installations of the IdP v3.X you could enabled the HTML Local Storage plugin whether you use client-side storage or server-side storage by setting the idp.storage.htmlLocalStorage property to true in idp.properties, see StorageConfiguration for more information and any implications.

SameSite and Single Logout

SP Front-channel SLO propagation from the IdP is facilitated using iframes, javascript, and in some cases HTML5 storage [LogoutConfiguration]. iframes that send SLO requests to SPs do not trigger top level navigation changes to the main browser document/window. As a result, same-site cookies will not be sent cross-site within the iframe - even when using 'safe' HTTP GET requests - unless the cookie is SameSite=None. Consequently, in cases where a principal's session state exists solely in a user agent in the form of a cookie, the SP must set the same-site attribute on the cookie to None - this is the responsibility of the SP.

For an SLO request to a Shibboleth SP the SP session cookie is optional, requiring only the NameID in the request, as a result SLO is unaffected for either HTTP-Redirect or HTTP-POST bindings.

The SOAP SLO binding uses backchannel communication and hence cookies are not relevant in this context.

Appendix A

the following algorithm returns “same-site” or “cross-site” (see [1]):

1. If “request”'s client is “null”, return “same-site”.
2. Let “site” be “request”'s client’s “site for cookies” (as defined in the following sections).
3. Let “target” be the registrable domain of “request”'s current url.
4. If “site” is an exact match for “target”, return “same-site”.
5. Return “cross-site”.

References

(1) https://tools.ietf.org/html/draft-west-first-party-cookies

(2) https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#page-42

(3) https://tools.ietf.org/html/draft-west-cookie-samesite-firstparty-00

(4) https://www.chromestatus.com/feature/5088147346030592

[5] Can I use… Support tables for HTML5, CSS3, etc

(6) https://datatracker.ietf.org/doc/draft-west-cookie-incrementalism/