Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saml2 SLO in IFrames with 3rd party cookies disabled #1452

Open
scleikas opened this issue May 16, 2024 · 4 comments
Open

Saml2 SLO in IFrames with 3rd party cookies disabled #1452

scleikas opened this issue May 16, 2024 · 4 comments
Labels

Comments

@scleikas
Copy link

Assume a case where:

  1. An ASP.NET MVC web application is using cookies for authentication
  2. The iDP does SLO only through Front-Channel -- in practice, by opening session participants' logout endpoints in Iframes. In the case of Sustainsys.Saml2, that would be the /Saml2/LogOut endpoint

As I've understood, the default endpoint just tries to clear authentication cookies automatically. And in order for this to work, the authentication cookie needs to be set with a SameSite=None setting, to make it a 3rd party cookie.

However, when 3rd party cookies are blocked by the browser, the browser will also reject the Set-Cookie headers from the default endpoint.

Because the user's session can't be invalidated through cookies, this requires us to invalidate the session at "server-side". This could probably be achieved for example, by using the idP's SessionIndex (and/or NameID), which we normally get from the identity's claims.

But in the SLO case done in an Iframe, the user's claims aren't available e.g., in the LogoutCommandResultCreated event, because the browser won't send any cookies to the server in an Iframe.

So, I was wondering if there's a way to "hook in" to the SLO event so that we could execute custom actions based on the SessionIndex?

I'm sorry if this has been covered in the docs.

Thanks for all your work on the library!

@AndersAbel
Copy link
Member

This library has it's origins since way before the SameSite attribute was available on cookies. And browsers blocking third party cookies was not even thought of back then.

The situation now is different and I think that for cross site scenarios the only reliable solution would be to implement support for back-channel logout. It is on my list of feature I want to get implemented in v3, but that is still work in progress and nothing available.

If you have urgent needs for getting this solved, I am open for a commercial discussion to get a fix into the library (for commercial customers I do work on both V1, V2 and V3, as requested).

@scleikas
Copy link
Author

Hi Anders,

And thanks for your reply!

I acknowledge that the issue is only related to recent changes in web browsers and I also agree that the back-channel logout seems like the only really good option for this. The problem is that the iDP doesn't currently support back-channel SLO, so I will need to discuss the options with our client.

@AndersAbel
Copy link
Member

I understand. The front-channel logout system with Saml2 actually often works better than Ws-Fed and OIDC with cookies blocked. Saml2 is expected to redirect the top level window which is somewhat more permissive for cookies. I know that many implementations actually use an iframe instead of a top level redirect, and then we're back in the same situation as OIDC and WS-Fed with cookies being blocked in iframes.

@scleikas
Copy link
Author

This implementation indeed uses IFrames. Actually the fact that Saml2 expects the top-level window to be redirected, was news to me. With this info, it seems to me like the correct fix for this would be for the iDP to implement the front-channel logout correctly, instead of using Iframes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants