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 rolled out the same change and then they subsequently appear to have reverted it with no public notice sometime later.

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.

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 user 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?

Originally, Apple, but this is less of a concern now. Very old Safari versions do not handle the SameSite header properly and will malfunction, but most of these versions are far enough back now to present a low risk. There are also some older Chrome versions affected on mobile, but again, fairly far back.

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, and the same goes if you’re relying on SAML proxying.

Beyond these considerations, it’s simply something that one typically would not want to change just for the sake of changing it, as there are CSRF mitigation benefits from leaving the setting alone, as was originally the intent.

Doing Something

IdP V5.2.0+ / Servlet API 6+

The version of Java EE required for V5.2.0 of the IdP (and that earlier versions do support) includes generic support for cookie “Attributes”, including SameSite. As a result, we have re-implemented the support for SameSite to leverage the standardized features in the API and in the various containers.

For the container’s own cookie, the newly shipped web.xml descriptor file contains a commented section under <cookie-config> that will override SameSite as desired. Note that this cannot be done conditionally, as that is not a feature containers support. This is the main step needed to avoid problems with proxying. The “delivered” copy of this file can be found in dist/webapp/WEB-INF/web.xml and you may override it (or modify your existing overridden copy) via edit-webapp/WEB-INF/web.xml (and a subsequent rebuild of the warfile).

If you also wish to override SameSite for the IdP’s own cookies, which is typically less urgent, then you may do so as before by using the idp.cookie.sameSite and idp.cookie.sameSiteCondition properties, as described in the section below. It functions the same as before, just via a different body of code.

IdP V5.0/5.1 / Servlet API 5

On older versions, 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 Jetty and Tomcat both have proprietary and mutually incompatible methods for injecting SameSite into cookies, including JSESSIONID, but not in a standardized way.

The filter is pre-installed by default but even when present, it is also 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.