FAQ

How does SAML SSO work?

Please refer to the SAML Technical Overview.

Why is SameSite=None required?

SAML protocol exchanges are, in most use cases, cross-site. The identity provider (IdP) and service provider (SP) are different sites. Furthermore, these flows do not involve users clicking navigation links from one site to the other. For example, when an IdP sends an SP a SAML response, it returns a 200 HTTP response to the browser containing an HTML form and some JavaScript to automatically submit the form to the SP via an HTTP Post. From the browser's perspective, the current site is the IdP and destination site for the HTTP Post is the SP.

If the SAML session cookie is marked as SameSite=Strict, the browser won't include it with the SAML response as the sites are different. If the SAML session cookie is marked as SameSite=Lax, the browser still won't include it as this isn't considered a top-level navigation action. Specifically, the SameSite specification doesn't consider Post to be a safe HTTP method.

Consequently, the SAML session cookie is created with a SameSite value of None.

These considerations aren't specific to SAML SSO. Other external authentication protocols potentially have the same issues.

No cookie, not just the SAML session cookie, marked as Strict or Lax will be included with the HTTP Post. This may impact other aspects of the site's functionality.

It may be required to set the application cookie as SameSite=None as well.

Are multi-server deployments supported?

Yes. However, for multi-server deployments not using sticky sessions or session affinity, SAML session state and other cached information must be stored in a central repository rather than using the default implementation which is server memory.