Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

SameSite Cookie and Unsolicited response error due to lost session ID

See original GitHub issue

saml2 complains that it cannot find the outstanding query which was saved to cache by djangoSaml2. Is there a configuration option I am missing? Below are relevant log messages:


DEBUG /usr/local/lib/python3.5/dist-packages/djangosaml2/views.py:250 views: Saving the session_id in the OutstandingQueries cache: id-ZEV53y7Cx2PoA3Pfe
...
/ERROR /usr/local/lib/python3.5/dist-packages/saml2/response.py:540 response: Unsolicited response id-ZEV53y7Cx2PoA3Pfe not found in {}

I altered saml2 error message to print the self.outstanding_queries being searched which turns up empty.

Am I missing some configuration, or is this a bug?

IDP is Microsoft azure I have no access to however is returning a successful login before this error.

Issue Analytics

State:
Created 3 years ago
Comments:9 (5 by maintainers)

Top GitHub Comments

1reaction

Rjevskicommented, Jul 27, 2020

The problem is most likely the “SameSite” and HttpOnly cookie restrictions. Basically if you’re using the HTTP POST binding, the POST is initiated via JavaScript on the IdP-supplied page which will not include the Django session cookie, thus the outstanding queries being empty because there is no session. You can check that by doing the flow while having the browser’s developer tools “network” tab open and then checking the cookies on the /saml2/acs POST request. You should see your session cookie in there for the “outstanding sessions” logic to work but you most likely won’t.

Potential solutions:

Set SameSite=None (and the Secure flag since it’s required in that case) on the Django session cookie. This might have detrimental security-related side-effects so I wouldn’t recommend.
Amending the library to use a different, separate session (with SameSite=None) only for the SAML outstanding queries cache, and keep the default Django session untouched (and secure; with default SameSite settings).
Allowing unsolicited responses in your SAML config. This might have security implications (which I’m trying to determine at the moment as I am facing the exact same issue).

0reactions

peppelinuxcommented, Jul 31, 2020

Implemented SameSite workaround in v0.30.0