CanSloAsync() returns false

SAML for ASP.NET Core
1

In sp-iniated slo case, when calling ssoStatus.CanSloAsync(); it always returns false. And ssoStatus.IsSloCompletionPending(); returns false too.
What’s the problem behind, how can troubleshot this problem?

2

CanSloAsync returns false if there’s been no previous SSO or if there has but there’s no single logout service URL configured for the partner provider.

If there’s still an issue, 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

3
[quote]
ComponentSpace - 3/15/2020
CanSloAsync returns false if there's been no previous SSO or if there has but there's no single logout service URL configured for the partner provider.

If there's still an issue, 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
[/quote]

Hi there,
The tricky part is it works locally but when I publish to Azure, it failed logout.
Another thing that I just noticed is that once I clicked the 'logout' button, when it redirects to another exception page, the cookie value of 'saml-session' changed. Is it because those values do not match?
Btw, just to confirm that once a sso completes, both idp and sp will have a cookie named "saml-session" right? And they should have same value? Will to results to slo failure if the idp site does not hold this 'saml-session' cookie?

Thanks
4

We use the saml-session cookie to remember the previous SSO state so we can support SLO. If the saml-session cookie isn’t presented by the browser, it will be initialized with a new value and any previous SAML session state will be lost.

If both the IdP and SP applications are using our library, both will have a saml-session cookie. If both applications are running on the same host the saml-sessoon cookie value will be the same.

You may be running into issues with the recent Chrome update (version 80) which has changed the default behaviour of the SameSite cookie property. For more information, please refer to:

https://www.componentspace.com/Forums/10491/SAML-Cookie-SameSite-Mode-None

5
[quote]
ComponentSpace - 3/15/2020
We use the saml-session cookie to remember the previous SSO state so we can support SLO. If the saml-session cookie isn't presented by the browser, it will be initialized with a new value and any previous SAML session state will be lost.

If both the IdP and SP applications are using our library, both will have a saml-session cookie. If both applications are running on the same host the saml-sessoon cookie value will be the same.

You may be running into issues with the recent Chrome update (version 80) which has changed the default behaviour of the SameSite cookie property. For more information, please refer to:

https://www.componentspace.com/Forums/10491/SAML-Cookie-SameSite-Mode-None
[/quote]

Thank you! When I was debugging, I found out that the idp site doesn't have this 'saml-session' cookie, will this result in fail of SLO?
6

I’m assuming your site is the SP. What happens at the IdP as far as session state and cookies is independent from your SP. You mentioned that the saml-session cookie value changed. This indicates the SAML session state has been lost and I suspect it’s caused by the Chrome 80 change I mentioned.

7
[quote]
ComponentSpace - 3/16/2020
I'm assuming your site is the SP. What happens at the IdP as far as session state and cookies is independent from your SP. You mentioned that the saml-session cookie value changed. This indicates the SAML session state has been lost and I suspect it's caused by the Chrome 80 change I mentioned.
[/quote]

Hi team,

Thanks so much! Indeed it's the SameSite problem!
8

Thanks for the update.