Open ambsw-technology opened 4 years ago
I'm currently dealing with a situation where I have a signed request and an unsigned assertion. Would it make sense to expose the pysaml2 options within the SAML2_AUTH config?
The maintainer's philosophy seems to be "simplest possible" so additional settings probably won't get accepted. The change I propose should be at least as secure and address your case as well so it's probably the path of least resistance. FWIW while I posted the issue here (to help others), I'm using a pretty hard fork (note branch name). I don't love the indirection but was trying to replicate the current code exactly while opening the door for large-scale modification using plugins -- for example my inline metadata plugin.
I support that line of reasoning.
Turns out, the team that manages our IdP is willing to make a change to my SP's config in order to support the assertion signature requirement; so, this is going to become a non-issue for me.
The current config requires assertion signing (vs. request signing). Since request signing is a superset of assertion signing, this should be equally secure. To provide flexibility, I suggest instead using the pysaml2 option
want_assertions_or_response_signed
.