SameSite

This is a summary of our current understanding of the impact of the Chrome SameSite change that has been well-publicized, and has been rolling out in recent Chrome (and now Edge, and other Chromium software) versions in a haphazard fashion. As of January 2022, Firefox has rolled out the same change.

If you want the gory details, we have a very technical testing summary 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.

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, unless they use the SAML proxying feature. This is because in all the tested and supported 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.

Note, however, that the SAML proxying feature is affected by this issue directly, because the POST back to the IdP from the proxied IdP may omit the necessary cookies to resume the flow, resulting in the "stale request" message. There are no alternatives but to get SameSite addressed if you use that feature with Chrome and its ilk.

Aside from the proxying case, 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 use server-side sessions OR is not using HTML Local Storage with client-side sessions.

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 and default (for new installs, since v4.0.0) 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.

SameSite and Frames

Note the caveat above of "tested and supported". The IdP officially does not support the use of frames, and the shipping defaults block frames. When this is disabled, and frames are used, the IdP will malfunction during logins within a frame when the top level origin is third party (e.g., when an SP creates a frame that surrounds the eventual login request to the IdP). This is because SameSite=lax cookies are not sent within a frame, even when the GET method is used. In effect, it's another frame-breaking feature alongside blocking third-party cookies, but unlike that blocking, it is possible for the server to work around the block by setting SameSite to None. So that is a scenario that may motivate using the workaround described below.

Logout is impacted heavily by this issue on the SP side, but the IdP generally hosts the page containing the frames and so responses back to the IdP in those frames are not a cross-site transfer that tends to block cookies due to SameSite.

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. There are also some older Chrome versions affected on mobile. We don't think the work is worth the gain at present (unless you’re proxying of course). 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.

Of course, if you have to support applications that use frames around the IdP, then you may not have a choice, per the note above.

Doing Something

The IdP includes a Java servlet filter class that can be deployed to work around Java's lack of SameSite support and auto-add the attribute to cookies in various ways. It does have a generic extension point for attaching a condition that can be used for User-Agent testing.

Note that current versions of Jetty and Tomcat both have proprietary and mutually incompatible methods for injecting SameSite into cookies, including JSESSIONID, but neither provides a practical means of doing so conditionally. As a result, we have no plans to support or make use of either of those mechanisms.

The filter is pre-installed by default now, but upgraded systems with web.xml modifications would need to import those additions from the delivered version. Even when present, it is disabled by default.

A pair of properties, idp.cookie.sameSite and idp.cookie.sameSiteCondition, control the operation of the filter. The former sets the default SameSite value to apply to all cookies, and the latter identifies a Predicate<ServletRequest> bean that controls whether the filter operates.

Again, for emphasis, enabling this globally (e.g., by setting the name of the condition bean to "shibboleth.Conditions.TRUE") 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. The condition hook is present to allow deployers to create scripted or Java-based code to perform User-Agent testing, which is not something this project believes in doing as a principle and so we do not intend to try and maintain such an approach.

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.