Version used:
componentspace.saml2.licensed.2.1.0 
saml-session is missing in the request of AsessertionConsumerService because the cookie got filtered out as the cookie was not set with SameSite mode to None. Not always this saml-session cookie is getting filtered out, only in some random cases this is getting filtered out and cookie is not being added to the further requests. We see new cookie is being issued in response by AsessertionConsumerService, and the redirection happens to /Identity/Account/ExternalLogin?handler=Callback which is not expected. We also understand from the componentspace forums that this redirection is happening because the cookie is not being identified.
Challenge call
After response:
We see new cookie is being issued in response by AsessertionConsumerService as the original cookie is beibng filtered out
Referring to this link https://www.componentspace.com/forums/9518/samlauthenticationhandler-challenge-redirecturi, added cookie policy to MinimumSameSitePolicy = SameSiteMode.None but this is not taking into effect and still we see the saml-session cookie without Same site none. we are not sure why chrome filters out only at sometime but allows even cookie to taken in request? Could you please let us know what is other configurations we need to set in order to add same site mode to saml-session cookie?
In the third image, it appears all the request cookies have been blocked, not just the saml-session cookie. Is that the case?
What exactly is the message when you hover over the icon in the SameSite column?
For example:
https://www.componentspace.com/forums/11875/Troubleshooting-Missing-Cookies
You said this happens randomly. Do you mean for a given user with a given browser it sometimes works and sometimes fails? Or does it consistently fail for certain users?
Are you using Chrome’s Incognito Mode? By default, this blocks 3rd party cookies.
As long as MinimumSameSitePolicy = SameSiteMode.None is specified for the cookie policy middleware, you should see SameSite=None for the saml-session cookie.
In the images, the saml-session response cookie doesn’t show SameSite=None so it looks like this hasn’t been set.
Do you see examples where it is set?
Hi Team,
Thanks for your quick response.
Yes, for same user, sometimes fails, at that time I see cookie is blocked and ACS sends new cookie.
No, Not using Incognito Mode
Below is how the configure Services and configure method is setup for enabling samesite mode to None
ConfigureServices
ConfigureDataProtection(services, config);
services.Configure(options =>
{
options.MinimumSameSitePolicy = SameSiteMode.None;
options.HttpOnly = HttpOnlyPolicy.Always;
options.Secure = CookieSecurePolicy.Always;
});
services.AddSaml();
Configure
app.UseStaticFiles();
app.UseCookiePolicy();
app.UseCorsCredentials();
app.UseIdentityServer();
ACS Request Cookies
Challenge Call
Note:
When I set options.MinimumSameSitePolicy = SameSiteMode sets as empty. When I set as Strict/Lax then i am able to see the setting getting reflected in browser application cookie section, only when i set None it is shown as Empty and getting into filtered out list in ACS response;
I also see, last used saml-session is being taken for new Challenge request but it is blocked and ACS sends new cookie
The configuration of the cookie policy middleware looks correct.
However, if you never set SameSite=None for the saml-session then something must be stopping it from being set.
My questions:
1. Is it just the saml-session cookie that’s missing SameSite=None? It appears from the images you provided that other request cookies are being blocked possibly for the same reason.
2. In some images the saml-session response cookie has the Secure property set and in others it doesn’t. The Secure property should always be set. Do you know why it’s set sometimes only?
3. When SSO works, do you see the saml-session cookie with the SameSite=None and Secure properties?
4. Any ideas why it works sometimes and not others for a given user? I find it confusing that this would occur given the problem looks more like it’s server side.
5. Please run the ExampleServiceProvider project we ship in the Visual Studio debugger and use the browser developer tools to check the saml-session cookie. Do you see the SameSite=None and Secure properties?
6. Version 2.1.0 of the SAML library is five years old. Is this just a recent issue that’s started occurring? If so, any ideas what changed?
To help investigate further, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.
https://www.componentspace.com/forums/7936/Enabling-SAML-Trace
Also, please use the developer tools to capture the network traffic and send the exported HAR file as an email attachment. Make sure to close all browser instances beforehand to clear any session cookies.
If you can capture both a successful SSO and a failing SSO in two separate HAR files for comparison that would be ideal.
Thanks.
Sorry for the delay, Took time to check our application for why the SameSite is set to Empty, we set the cookie path with a hack mentioned in other forum c# - How to set SameSite cookie attribute to explicit None ASP NET Core - Stack Overflow and after setting as mentioned, now we see saml-session cookie with SameSite as None and we are able to get the redirection to expected callback page. But we are still not sure why we need to do this hack and not cookie policy option is not setting the saml-session cookie samesite mode as None.
services.Configure(options => {
options.CookieOptions.Path = “/; SameSite=None”;
options.CookieOptions.HttpOnly = true;
options.CookieOptions.Secure = true;
});
Question:
is this cookie saml-session name will only be generated in componentspace.saml2.licensed.2.1.0 and different cookie name will be generated for all upper versions?
The hack shouldn’t be necessary. The product version you’re using is over 5 years old. Perhaps you could try upgrading to see if that makes any difference.
The saml-session cookie is still used in the latest version of the product. The default name for this cookie is “saml-session” but you can change this if required.