Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
The testing methodology has been updated. All previous tests were run with the IdP configured to allow the storage of sessions in client side HTML local storage (idp.storage.htmlLocalStorage=true). This has the effect of enabling SSO when using the HTTP-POST binding even when cookies are defaulted to SameSite=Lax, or even when using server side session storage. Without it, SSO will fail when initiated using the HTTP-POST binding from a cross-site SP, and the user will be always presented with the login page. 
Warning
titleTesting Update
Note

If you're looking for concise conclusions about the impact of SameSite on the Shibboleth software, please refer to the relevant topics under Productionalization in each software product's documentation space. This page is the underlying research and testing summary developed by the project over the last several months and used to inform project decision making. It's more technical and not organized into an easily digestible form.


Table of Contents

Jira Issue

...

BrowserSameSite SupportCan enable SameSite Lax By DefaultCan enable SameSite None requires Secure by defaultSameSite Lax enabled in browser by defaultSameSite None requires secure enabled in browser by default
Firefox desktopv60 onwardsin advanced setting/preferences (about:config) from v69in advanced setting/preferences (about:config) from v69unknown but likely to happenunknown but likely to happe
Chrome desktopv51 onwardin experimental features (chrome://flags) from v76in experimental features (chrome://flags) from v76Stable Chrome 80 (aprox. Feb 4th 2020,https://chromiumdash.appspot.com/schedule). Although likely to be the default in Chrome Beta 79.Stable Chrome 80 (aprox. Feb 4th 2020,https://chromiumdash.appspot.com/schedule).Although likely to be the default in Chrome Beta 79.
Safari desktopv12 onward**unknownunknownunknownunknown
Opera desktopv39 onwardin experiments (opera://flags/) from 63 onwardin experiments (opera://flags/) from 63 onwardlikely to follow chrome as chromium/blink based.likely to follow chrome as chromium/blink based.
Edgev16 onwardpossible in Edge builds based on chromium 76 onward (2019). Not sure about older EdgeHTML engines. In experimental features (edge://flags)possible in Edge builds based on chromium 76 onward (2019). Not sure about older EdgeHTML engines. In engines - looks like that will NOT happen in IE or Edge <v18. In experimental features (edge://flags)possible in Edge builds based on chromium 76 onward (2019). Not sure about older EdgeHTML engines - looks like that will NOT happen in IE or Edge <v18. In experimental features (edge://flags)likely to follow chrome as in 2019 Edge became chromium/blink based.likely to follow chrome as in 2019 Edge became chromium/blink based.
Warning
title** Safari Issue

Webkit based browsers on Mac (safari) and iOS (safair, chome, firefox etc)  are currently affected by a bug that treats SameSite=None or SameSite=nonesense cookies as SameSite=Strict (https://bugs.webkit.org/show_bug.cgi?id=198181). We believe the fix for this will only take effect from MacOS 10.15 and iOS 13. Consequently, any attempt to maintain the current functional behaviour of cookies by setting SameSite=None on unpatched versions of Webkit will break SSO.

This bug also affects older Chrome and Android browsers.

Warning
titleFirefox issue

To compound matters, Firefox has a bug filed (https://bugzilla.mozilla.org/show_bug.cgi?id=1465402) that suggests they may consider the ability to set even Lax cookies in the middle of SP→ IdP → IdP redirect chains to be a bug. If they decide to "fix" this non-bug, it will cause the current default behavior to stop functioning correctly at all with Firefox because the JSESSIONID cookie set upon initial contact to the IdP will be ignored, and the follow-on request will trigger a flow exception error. This would make "doing nothing" a non-option and create a hopeless situation without ugly workarounds to accomodate three different non-overlapping modes of behavior.

...

likely to follow chrome as in 2019 Edge became chromium/blink based.likely to follow chrome as in 2019 Edge became chromium/blink based.
Warning
title** Safari Issue

Webkit based browsers on Mac (safari) and iOS (safair, chome, firefox etc)  are currently affected by a bug that treats SameSite=None or SameSite=nonesense cookies as SameSite=Strict (https://bugs.webkit.org/show_bug.cgi?id=198181). We believe the fix for this will only take effect from MacOS 10.15 and iOS 13. Consequently, any attempt to maintain the current functional behaviour of cookies by setting SameSite=None on unpatched versions of Webkit will break SSO.

This bug also affects older Chrome and Android browsers.

Warning
titleFirefox issue

To compound matters, Firefox has a bug filed (https://bugzilla.mozilla.org/show_bug.cgi?id=1465402) that suggests they may consider the ability to set even Lax cookies in the middle of SP→ IdP → IdP redirect chains to be a bug. If they decide to "fix" this non-bug, it will cause the current default behavior to stop functioning correctly at all with Firefox because the JSESSIONID cookie set upon initial contact to the IdP will be ignored, and the follow-on request will trigger a flow exception error. This would make "doing nothing" a non-option and create a hopeless situation without ugly workarounds to accomodate three different non-overlapping modes of behavior.

Testing

Warning
titleTesting Update

The testing methodology has been updated. All previous tests were run with the IdP configured to allow the storage of sessions in client side HTML local storage (idp.storage.htmlLocalStorage=true). This has the effect of enabling SSO when using the HTTP-POST binding even when cookies are defaulted to SameSite=Lax, or even when using server side session storage. Without it, SSO will fail when initiated using the HTTP-POST binding from a cross-site SP, and the user will be always presented with the login page. 

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.

...