Bug: SAMLRequest Session Lost

[askvortsov1]

I've been bumping into a really odd bug lately, and I can't seem to get anywhere with it, wanted to ask if you have any ideas @mhindery

The error is:
KeyError at /idp/login/process/'SAMLRequest'

It occurs at LoginProcessView, when the SAMLRequest is pulled from the session after authentication. It seems that for some odd reason, in some cases, the request session is wiped after being set in the sso entry view, but not immediately? Here's what I've tested so far:

• I go to the SSO entry view with a valid SAMLRequest. It's stored in the session (tested by printing to console).
• I get redirected to a login page (it's not an issue with the login page, as I manually added in a redirect to a completely blank page, and the same issue occured). Prior to page load, the request session is still there (tested by printing to console).
• If I redirect the page, or visit any other page, the request session is gone. Essentially, it looks like sometimes, something is prompting the browser to unset the session cookie after visiting the sso entry page.

This bug is "fixed" on the client side by clearing cache and cookies. While I know this, it's also been happening to my end users which is an issue. I'm particularly confused because I'm not sure what exactly causes this to spring up. Any thoughts?

[askvortsov1]

Looks like clearing "cookies and site data" fixes this for a given instance, would still be nice to find the root cause. Cache is unrelated.

[peppelinux]

Hi @askvortsov1
It sound to me like a SameSite cross domain cookie POST prevention.

A question: is this bug related to a SP wth a domain different from that of the IdP?
This would confirm my thesys.

Yesterday I've implemented SameSite cookie workaround in djangosaml2 and today in uniAuth (in branch refactor, is it in the milestone for release v2.0.0).

Confirm is SameSite is involved, if it true I'd drive you on which would be trivial for you to implement in djangosaml2idp.
regards

[challet]

I had a similar issue with a SameSite=Lax session cookie. It can be seen by inspecting the request made for the cross domain form submit (from the SP page) and see if the session cookie of the IDP is present in the request headers.
If not, Django immediately sets a new session id, which is the same than flushing the pre-existing session. SameSite=None would be the basic way to avoid this.