-
Notifications
You must be signed in to change notification settings - Fork 6.2k
Description
Current Behavior
The OpenSamlMetadataResolver currently hardcodes the WantAssertionsSigned flag to true. There is some (speculative) evidence1 this causes some Identity Providers to sign the assertions instead of the response. However, as discussed in #9044 Spring Security will only decrypt assertions if the response is signed.
Expected Behavior
There are 3 (technically 4) signing modes:
- Signing only the response
- Signing all the assertions
- Signing both the response and the assertions
- Signing nothing
- I don't think the SAML specification actually allows this
The SAML specification does not seem clear to me as to what WantAssertionsSigned is used for. And there seems to be no flag to want the response signed. But it does seem to require that either the response or the assertions need to be signed, and signing both seems redundant.
So either:
- Do not set
WantAssertionsSigned. The SAML specification should be enough to have either signed. - Make the
WantAssertionsSignedflag configurable.
Neither of these options will force the Identity Providers to sign the response. So users might still have to manually configure them to sign it.
Context
What are you trying to accomplish? Making it slightly more easy to configure (some) Identity Providers by having correct defaults.
What other alternatives have you considered? SInce all methods in OpenSamlMetadataResolver are private, and the XML string is produced before there is any hook to update the SPSSODescriptor before it is serialized means the only way to change things is to completely copy the OpenSamlMetadataResolver.
In fact, allowing some overrides on the SPSSODescriptor might also allow some other customizations like adding more AssertionConsumerServices
Are you aware of any workarounds? Most Identity Providers can be manually configured to sign the response.