Chrome Samesite issue (Last updated 31 January)

Posted on Thursday, 30 January 2020

The way web browsers handle cookies is changing soon. This can have an impact on some configurations of Identity Providers and, Service Providers. The impact may vary from no impact to 'Single Sign On stops working' (users are challenged for username/password every time) to 'entirely not working' depending on the configuration of your IdP or SP and the flow of HTTP messages between them. Please ensure this message is passed on to someone in your organisation who can check the impact on your service The updated UK federation webinar on this issue can be found here: https://youtu.be/avpj1FFXMZA

Background

UPDATE 2: Today (30 January) the Chrome team have indicated that this rollout will be for an initial limited population starting the week of February 17, 2020. They will be closely monitoring and evaluating ecosystem impact from this initial limited phase through gradually increasing rollouts. This does not change our recommendation to test your deployments as soon as you can. You should also check https://www.chromium.org/updates/same-site to see when it is going to happen

UPDATE: The current Chrome cookie hack to use LAX Samesite cookies in POST requests for the first 2 minutes after being set will be included in the Chrome v80 rollout, and will be dropped at some point after the stable launch which provides a additional time to test and fix. https://www.chromium.org/updates/same-site

On February 4th Google will release version 80 of their Chrome web browser. In this release, Google will enable a feature that implements their expired IETF draft 'Incrementally Better Cookies' (supported by Mozilla and Microsoft) . Any cookie which does not specify the Samesite attribute will be defaulted to 'Lax'. 'Lax' cookies are not sent in cross-site requests (top level navigations in the browser) for 'unsafe' HTTP methods such as POST. This browser change could have an impact on federated authentication mechanisms that issue authentication requests from service providers to identity providers using a HTTP POST request, as the identity provider sessions cookies will not be sent in the request, potentially breaking single-sign-on, or worse any identity provider functionality. This webinar aims to give a general understanding of the issue, highlighting the particular effects you can expect to see on the Shibboleth Identity Provider, and how to potentially mitigate against these effects.

Edited by SteveGlover on 31 January 2020, at 04:00 PM (Permalink)