You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 WantAssertionsSigned flag 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.
Thanks, @svschouw-bb. I think it's best to leave it unset since there is nothing in RelyingPartyRegistration to indicate a preference, especially in light of the ambiguities you researched.
I believe #10839 can take care of making it configurable.
WantAssertionsSigned requires that asserting parties sign the
assertions. This does not reflect how Spring Security actually
behaves, creating behavior mismatches.
Closesgh-10844
WantAssertionsSigned requires that asserting parties sign the
assertions. This does not reflect how Spring Security actually
behaves, creating behavior mismatches.
Closesgh-10844
Current Behavior
The
OpenSamlMetadataResolver
currently hardcodes theWantAssertionsSigned
flag totrue
. 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:
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:
WantAssertionsSigned
. The SAML specification should be enough to have either signed.WantAssertionsSigned
flag 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 theSPSSODescriptor
before it is serialized means the only way to change things is to completely copy theOpenSamlMetadataResolver
.In fact, allowing some overrides on the
SPSSODescriptor
might also allow some other customizations like adding more AssertionConsumerServicesAre you aware of any workarounds? Most Identity Providers can be manually configured to sign the response.
Footnotes
"Evidence": https://stackoverflow.com/questions/60159390/sp-metadata-wantassertionssigned-false-or-true#comment106438963_60159390 ↩
The text was updated successfully, but these errors were encountered: