Come February 2020, Single Sign-On (SSO) with some Identity Providers (IdPs) will break for Chrome users. Google will enable SameSite flag cookie enforcement to its Chrome browser currently planned for version 80, due in early February 2020 and for beta users earlier.

This effectively breaks reauthorization via POST binding after the service provider (your SSO-enabled apps) session ends for IdPs that currently don’t set SameSite=None on their session cookies.

This is a move in an ongoing initiative of making the web safe by default, but it has the negative side effect of breaking certain integrations that are not prepared and rely on this functionality.

Note that this article only applies to the SAML SSO with POST binding. OIDC with session management is affected as well. SAML Redirect binding is not affected, other protocols should not be affected as well.

What will happen?

On the morning of February 4th 2020, when Chrome 80 is released, your SSO experience could look like this:

1. You visit Jira or any other SSO-enabled application for the first time with the newly updated browser.
2. Then, as usual, Jira would try to log your browser in by redirecting it to your identity provider.
3. But instead of this just going through unnoticed, you would be asked for your credentials.
4. You would enter them, a little bewildered, since you barely ever have to do that. But it would work.
5. Then you visit Confluence, and you would have to enter your credentials again. And on every other SSO-enabled application.
6. And then, when your sessions expire after a couple of hours, you would be asked again. For every application.

How did this happen?

Because the new default behavior in Chrome 80 is to assume SameSite=Lax for every existing cookie, the IdP’s session cookies are not sent during cross-origin POST requests, which is an essential step in how SAML POST binding works.

This means that when the service provider (our plugin for example) has the user’s browser send a POST request to the IdP, the session cookie that the user has on the IdP isn’t sent with this request. This causes the IdP to think think that the user is not logged in and prompts them for their credentials, even if the user has already logged in on that day.

My expectation is that this will affect a lot of users, especially if they use on-premise IdPs which are not updated as often as they should.

How to solve the problem?

We did some research for a solution. The best one is to Update your Identity Provider to a version that automatically sets the SameSite=None flag. Here is some information we have gathered on SameSite support:

IdP Vendor Support of SameSite=None cookie option (as of 2019-12-20)

We are aware that updating your IdP may not really be an option. We have done some research and found some possible mitigation techniques:

Option 1: Set flag at reverse proxy / load balancer

If an update is not yet available for your IdP and if you have a reverse proxy or load balancer in front of your IdP, you might be able to configure it to set the SameSite flag. The exact technique will vary based on the software you’re using.

When you implement this option, please note that older Safari versions on macOS and iOS devices interpret this setting wrongly and need to be exempt from this flag:  https://bugs.webkit.org/show_bug.cgi?id=198181#c24

Option 2: Use Redirect binding in SAML

If your Identity Provider supports Redirect binding as well, you can use another mitigation technique:

Changing the binding type to REDIRECT fixes this issue, since the new default behavior doesn’t impact the 302 redirects used in REDIRECT binding. Note that for some IdPs, changing the “Protocol Binding” setting to “None” or “Post” was also necessary.

To change the binding type in our SAML SSO app for Atlassian Server and Data Center products:

1. Navigate to the SAML SSO Configuration page
2. Click on Identity Providers tab in the middle panel
3. Scroll down to the Binding settings
4. Change the Login Binding to REDIRECT
5. Save the configuration

Option 3: Enterprise controls in Chrome

See https://www.chromium.org/updates/same-site for information on how to create an exception for your site if you’re using enterprise controls in Chrome.