This is a summary of our current understanding of the impact of the Chrome SameSite change that has been well-publicized, and is due to appear in Chrome 80 on February 17, 2020.

If you want the gory details, we have a very technical testing sumary page at IdP SameSite Testing. This is intended as a more digestible, actionable summary for deployers.

What about applications?

This is NOT intended as a statement about the correct behavior of literally any application or SP you have connected to your IdP. The IdP does NOT control the SameSite behavior or any problems that arise with any SP. It can't solve that for you, and despite all the finger-pointing coming your way, you should be prepared to be very firm on that point. A separate page regarding the implications for the Service Provider is here.

Based on our testing, we believe that in most cases today, the IdP is functional "enough" such that the advisable course of action for most deployers is to do nothing at present. This is because in all the tested cases, we have observed the IdP to be successful in getting users logged into services that aren't themselves broken in some way, with the only impact (in a subset of cases) being to reduce the frequency of SSO.

In particular, the following deployment scenario is one that results in loss of SSO functionality (the user has to enter their credentials again):

A SAML 2.0 SP uses the HTTP-POST binding to issue its request AND
The IdP is configured to rely on server-side sessions OR on client-side sessions without HTML Local Storage enabled.

(In turn, it's possible to get SSO back, even using server-side sessions, by enabling the idp.storage.htmlLocalStorage property, at the cost of users being forced to navigate the extra roundtrip used to load the data from the client.)

We believe this represents a relatively small minority of deployments, given that we strongly encourage use of client-side sessions and that HTML Local Storage is the advised, though not yet default, mechanism used to do so. POST requests are also relatively less common, and in some cases extremely rare, though some prominent SPs do use it (e.g. Box.com, EZProxy).

Even so, the users gets into their service and for most people, that's a lot more important than squeezing out every last drop of SSO potential.

We have tested logout to a lesser degree, but at least with respect to the IdP, we believe the software still works, though likely to a much lesser degree once SPs and applications are factored in.

Why Do Nothing?

Simply put, Apple. Fixing this today requires a very complex and to our mind unwarranted amount of User-Agent shenanigans or the immediate breakage of all older macOS and iOS Safari browsers. We don't think the work is worth the gain at present. Waiting until those versions can be dismissed to deploy the SameSite workaround is in our view the simpler course of action to take, though of course that wait may be infinite.

Doing Something

We have shipped a Java servlet filter class as part of the last IdPv3 patch release that can be deployed to work around Java's lack of SameSite support and auto-add the attribute to cookies in various ways. In its shipped form, it does not support any User-Agent testing, so it's more usable as a sample than a directly deployable filter.

The version that will ship with V4 does have a conditional feature to enable more use of it if required, and that Java class could be copied for use if desired in the interim.

Again, for emphasis, using this as is will break older Safari users, and by "break" we don't mean "SSO doesn't happen". They will be non-functional in pretty much all cases.

To deploy the current version, you would add the following to conf/global.xml:

Add to global.xml

    <bean id="custom.SameSiteCookieFilter"
        class="net.shibboleth.utilities.java.support.net.SameSiteCookieHeaderFilter"
        p:defaultValue="None" />

And add the following to edit-webapp/WEB-INF/web.xml, followed by rebuilding and deploying the warfile. You may of course need to create the web.xml file as a copy of the version in dist/webapp first.

Extend web.xml

    <!-- Automates SameSite handling until Java API catches up. -->
	<!-- Should go ABOVE the CookieBufferingFilter in the current file. -->
    <filter>
        <filter-name>SameSiteCookieFilter</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
        <init-param>
            <param-name>targetBeanName</param-name>
            <param-value>custom.SameSiteCookieFilter</param-value>
        </init-param>
    </filter>

...
	<!-- Again, place ABOVE the mapping for the CookieBufferingFilter. -->
    <filter-mapping>
        <filter-name>SameSiteCookieFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Risk Factors

This is all very much subject to change with the decisions of browser makers. We know only what has currently been announced and planned, and what we have observed in the currently implemented features of the major browsers. We do have concerns that future versions of other browsers may implement much more strict variations of this Chrome change, and this could make the situation much more dire very quickly, and change our recommendations.