want_assertions_or_response_signed vs want_assertions_signed

[ambsw-technology]

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.

[kmarchiori]

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?

[ambsw-technology]

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.

[kmarchiori]

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.