-
Notifications
You must be signed in to change notification settings - Fork 123
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
Unsolicited Response: KeyError exception when allow_unsolicited = true #330
Comments
Hi @senorkrabs, can you share your changes in the code? |
Looking at #232 I thought this was reverted and that actual PR was never merged. I couldn't find it in the source. I made some minor modifications to the original PR code and put it here: https://github.com/senorkrabs/aws-saml-proxy/blob/master/satosa/frontends/saml2_custom.py. It worked with 6.x but haven't tested in 7.x yet. Edit: This was needed for the frontend microservice so that I could create idp-initiated requests. If there's another or better way to do this, it would be great to know. I also added |
Probably a diff might help In my environment that problem Is often linked to clients that start sessions directly from the Discovery service. Once the auth happens, when they come back to satosa, this cannot link the response to any previous states... Key error |
FWIW, we ran into the same issue today and the cause turned out to be that we attempted to use SATOSA over unencrypted HTTP. Since the Set-Cookie header has |
Code Version
latest (6.1.0)
Expected Behavior
I'm working with an SP that does not support sp-initiated requests. Ideally, I would like to use do something like:
SAMLFrontend Idp-initated request (specifying Target SP) > SAMLBackend > Target IdP (shibboleth) > SAMLBackend > SAMLFrontend > SP ACS with RelayState=https://some.target.url
Based on the docs, it doesn't appear that Satosa/pysaml2 have a way of supporting this, so I'm trying to enable unsolicited responses to the SAMLBackend and do this instead:
Target IdP (shibboleth) Idp-initiated request with RelayState=https://some.target.url > SAMLBackend > SAMLFrontEnd > SP ACS with RelayState=https://some.target.url
Note: I'm not sure if using unsolicited responses from the SP will work, since I'll need a way to tell the SAMLFrontend what SP to response to. I'm open to other approaches, but the SP supporting sp-initiated auth is not an option at this time.
Current Behavior
After receiving the assertion from the Target IdP, Satosa throws the following error:
Possible Solution
I believe the SAMLBackend is attempting to compare a stored RelayState value that doesn't exist because the response was unsolicited.
Steps to Reproduce
The text was updated successfully, but these errors were encountered: