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.

However, if the MinimumSameSitePolicy for the application is set to SameSiteMode.Lax or SameSiteMode.Strict, the SAML session cookie will take on this minimum setting. This will mean the browser won't return the cookie and the corresponding SAML session state cannot be identified.

To circumvent these issues, the recommended approach is to set MinimumSameSitePolicy to SameSiteMode.None and to specify the SameSite setting on individual cookies as required.

builder.Services.Configure<CookiePolicyOptions>(options =>
{
  options.MinimumSameSitePolicy = SameSiteMode.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.

builder.Services.ConfigureApplicationCookie(options =>
{
    options.Cookie.SameSite = SameSiteMode.None;
})

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.

The SSO session store, ID cache and artifact cache all use IDistributedCache.

An IDistributedCache implementation with a central repository such as the RedisCache or SqlServerCache should be used.

For more information, refer to the article Distributed caching in ASP.NET Core.