Skip to content

SAML metadata WantAssertionsSigned might cause Identity Providers to not sign response #10844

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

Closed
svschouw-bb opened this issue Feb 17, 2022 · 2 comments
Assignees
Labels
in: saml2 An issue in SAML2 modules type: bug A general bug
Milestone

Comments

@svschouw-bb
Copy link
Contributor

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:

  1. Signing only the response
  2. Signing all the assertions
  3. Signing both the response and the assertions
  4. 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:

  1. Do not set WantAssertionsSigned. The SAML specification should be enough to have either signed.
  2. 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.

Footnotes

  1. "Evidence": https://stackoverflow.com/questions/60159390/sp-metadata-wantassertionssigned-false-or-true#comment106438963_60159390

@jzheaux
Copy link
Contributor

jzheaux commented Feb 17, 2022

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.

@jzheaux jzheaux added in: saml2 An issue in SAML2 modules type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement labels Feb 17, 2022
@jzheaux jzheaux added this to the 5.7.0-M2 milestone Feb 17, 2022
@jzheaux jzheaux self-assigned this Feb 17, 2022
jzheaux added a commit that referenced this issue Feb 18, 2022
WantAssertionsSigned requires that asserting parties sign the
assertions. This does not reflect how Spring Security actually
behaves, creating behavior mismatches.

Closes gh-10844
@marcusdacoregio marcusdacoregio modified the milestones: 5.7.0-M2, 5.7.0-M3 Feb 21, 2022
@jzheaux jzheaux modified the milestones: 5.7.0-M3, 5.7.0-M2 Feb 22, 2022
@jzheaux
Copy link
Contributor

jzheaux commented Feb 22, 2022

Closed via 3d87854

@jzheaux jzheaux closed this as completed Feb 22, 2022
jzheaux added a commit that referenced this issue Feb 22, 2022
WantAssertionsSigned requires that asserting parties sign the
assertions. This does not reflect how Spring Security actually
behaves, creating behavior mismatches.

Closes gh-10844
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: saml2 An issue in SAML2 modules type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants