[SameSite Cookie] Session not cleared on logout and unsolicited response Error

[OskarPersson]

I've setup a djangosaml2 application where I successfully can login using ADFS. When I logout I get no error but as soon as I go to the login page again I'm automatically signed in to the same user without any chance to change user.

I receive no error when logging out, I get a LogoutResponse with the following status so it doesn't look like anything has gone wrong:

<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status>

Is there something I must configure in the settings for djangosaml2 or is there something that must be done on the ADFS side?

[peppelinux]

The problem is not related to Django session - or djangosaml2 - but to the fact that you've not configured the SLO or the ADFS make things with the session cookie that belong to him.

I think that you succesfully being logged out by djangosaml2 but when come back to a protected resource, djangosaml2 starts again an AuthnRequest to the IdP and in this latter your session is still alive, so it returns a Authn Response. I'd investigate more on the IdP behaviour.

The final solution would be: force_authn in your pysaml2 sp configuration :)

[Rjevski]

I'd like to suggest you reopen this, I am noticing the same issue with a different IdP and it's definitely not got anything to do with the IdP immediately logging me back in (the logout works and I end up logged out of the IdP so no chance for it to automatically log me back in, and even force_authn doesn't change anything).

The problem is that in the logout view, we seem to forget calling auth.logout(request) if SP-initiated logout is indeed supported (we do call it otherwise though). Instead we redirect to the IdP's logout URL as we're supposed to, however we still have a valid, logged-in Django session. At that point I am not sure if there is value in keeping the Django session logged in (so far it doesn't look like it, and as such we should probably log-out the local session already), however all is not lost yet - we'll have another opportunity to logout the local session.

After being redirected/POSTed to the IdP and it does its logout flow on its side, it redirects back to the SP's logout endpoint (saml2_ls_post), which eventually calls the built-in Django logout function. However, due to SameSite restrictions on the session cookie (similar to this other issue), the Django logout doesn't do anything because there is no session to actually log out - the session cookie was not submitted due to SameSite restrictions. At this point we've wasted our last opportunity to logout the local session.

Solutions:

1. Look into why we don't just logout the Django session to begin with before even redirecting/POSTing to the IdP's logout endpoint, and if there are no reasons against it then just logout the session there.

2. As mentioned in the other issue, a solution for the SameSite problem is needed anyway, a separate cookie only for SAML-related things that would have the proper SameSite settings and thus would successfully be sent even for IdP-initiated POSTs. In that case the separate session for that cookie should contain a reference to the real Django session so during logout we can retrieve that session indirectly (since we don't have the cookie for that session in the request directly) and log it out.

3. Only use redirect bindings which should not be affected by SameSite cookie restrictions if such a thing is possible (my IdP doesn't seem to support anything but HTTP POST bindings for logout)

[peppelinux]

Please go deeper in this if you can, I don't have this problem with sessions, force_authn works fine on my IdPs. If you have a PR for this we'll be happy to analyze that in a useful time.

I pushed a SLO workaround that assumes what you explain in 1., here: https://github.com/knaperek/djangosaml2/blob/a155f5b0addb593cd45daf5d7e099e069a5d99d4/djangosaml2/views.py#L443

You're telling that, and I agree, that it works only if the IdP doesn't have a fully working logout service.
Then SP starts the logout request (without logout the user) BUT the IdP doesn't handle this in a proper way. Result: user still logged, in the SP.

2. Regarding SameSite I think that this topic was abused in the software that makes large use of cookies. It's not this way in django and personally I don't use cookie since 2009 (!). Regarding putting django session id references in cookies... I'd discourage this. Simply: do not use cookies!

3. Yes, even my IdP deal only with HTTP-POST Bindings! And also, if SameSite=strict the cookies will not be propagate even with Http Redirects (302).

We should discourage cookies, as if they never existed, and move to a solution that focuses on the problem that you want to face in a reproducible way. Consider my support in all this

[Rjevski]

Thanks for getting back to me so quickly!

We might have a misunderstanding here - to me the original post suggests that despite successfully logging out of the IdP (in which case force_authn is no longer relevant), when they come back to the Django app, they still have a local Django session logged into the local user model (created during the initial SAML login attempt). This is also consistent with the behavior I'm seeing.

Your linked workaround would only trigger upon a LogoutError being raised due to the IdP not supporting SP-initiated logout, and in that case it would work fine because the HTTP request to that view would be initiated directly by the user from the SP's domain, thus SameSite does not apply. However if the IdP does indeed support SLO, then we instead do a POST or redirect to them but omit to logout the session locally. When returning from the IdP (after it completed its own logout flow) we have one more opportunity to clear the session, however at that point SameSite restrictions do apply and prevent us from actually accessing that Django session to be able to log it out.

BUT the IdP doesn't handle this in a proper way.

My understanding is that the IdP is doing everything properly and is doing a POST to the ls_post endpoint, however due to SameSite restrictions, there is no way for anything during that request to access the original Django session, thus any attempts at logging it out (such as returning the default Django logout view) would fail because during that request, as far as Django is concerned there is no session at all because SameSite restrictions prevent the session cookie from being sent in that request.

I am not sure what alternative to cookies are you proposing. For Django to be able to maintain its "logged in" state (and be able to know which User model belongs to the current user) it has to use cookies (this is handled by the Auth middleware to provide request.user which itself relies on the Session middleware).

Also I did not mean to put a Django session ID directly in an unencrypted cookie; instead I suggested using a separate session (using its own middleware, mostly a subclass of the built-in SessionMiddleware but using a different cookie name and explicitly setting SameSite to None) in which to store both the outstanding queries (solves the previously linked issue) - at the moment the main Django session is passed to OutstandingQueriesCache, my alternative would be to pass the separate session to it instead so it wouldn't be affected by SameSite restrictions while keeping the main Django session untouched so it can take advantage of SameSite's security improvements. It would also then contain a reference to the main Django session so during logout we can lookup that session and log it out as well since the SameSite restrictions wouldn't send us the cookie of the main session.

As a workaround during development I have set settings.SESSION_COOKIE_SAMESITE = None and I can confirm that both the aforementioned login issue as well as the logout now work as expected.

If you want to try reproduce this on your end, make sure you have SameSite=Lax or Strict on your Django session cookie, login and then go to the /saml2/logout endpoint and follow your IdP's logout flow until you are redirected back to your application, presumably logged out. Then try to hit a "login required" endpoint such as the Django admin; you should see that despite you being logged out of your IdP, your Django session is still alive and logged in and thus you are given access to the admin UI.

[peppelinux]

Really thanks @Rjevski we would like to have a unit test to do that. Now I'm quite busy and as far I understand we're talking about a real bug.

If you are ready for a PR I would test and merge It asap, a particular attention would be on the unit test, to prevent the breaking changes.

Your description was really accurate and appreciable, Happy to met you here

[peppelinux]

In addition, I realized what you purposed, split the session handling SAML2 and django.
This is a good solution. Before going that way I'd prefer to build something durable for the future, I'm facing that djangosaml2 have unit test but not code coverage.

I opened an issue for this, that's the solution to see how this bug can be raised and how to cover it with unit tests.
Hope you agree.

At last but not least, tell me if you're ready to purpose a PR for this bug, I could deal with code coverage in parallel

[Rjevski]

Code coverage and better testing might help somewhere else, but in this case when talking about SameSite-related cookie issues, unit tests are unlikely to catch it unless you wanted to replicate the entire browser's behavior in the unit test. In a standard test using the Django test client, the cookie would be sent just fine because SameSite is irrelevant and the test client has no concept of first-party/third-party requests anyway.

[peppelinux]

This could be achieved with python requests or seleniumhq, would be interested in a PR that fix this bug asap.
Ok, code coverage is at 79%.
We should increment it at least of 10%.

As far I can see logout view is quite covered.
I think that we could move to pratical an fast solution, as @Rjevski suggested, we could log auth the use in https://github.com/knaperek/djangosaml2/blob/a155f5b0addb593cd45daf5d7e099e069a5d99d4/djangosaml2/views.py#L446, then send the logout Request to the IdP. When it come back from it, just verify signature and cleanup state cache.

That's could avoid to split the session management, django and SAML2.

[peppelinux]

@Rjevski what do you think about the last solution?
do you plan to contribute in this solution, or in another decided by you?