SAML SSO: Force AuthnRequestsSigned for relying party

[wsalembi]

Expected Behavior

We need a configuration for the relying party to indicate it wants to send a signed samlp:AuthnRequest. The value can be set in the OpenSamlMetadataResolver EntityDescriptorCustomizer, but it isn't used during SSO because Spring Security reads the Asserting Party
WantsAuthnRequestsSigned setting.

Current Behavior

Explained in #9564 Spring Security honors the WantsAuthnRequestsSigned published by the Asserting party. But this value is only a default. E.g. if you create relying parties in ADFS based on their published metadata file, ADFS will honor the SPSSODescriptor for that specific relying party and require a signed request.

The current implementation ignores sign-request if metadata-uri is configured. See Saml2RelyingPartyRegistrationConfiguration.java#L107

            assertingparty:
              singlesignon:
                sign-request: true  // value is ignored / cannot be overridden
              metadata-uri: https://domain/FederationMetadata/2007-06/FederationMetadata.xml

Context

I can configure in my relying party that I send signed requests. The asserting party expects signed requests because it is declared in the RP metadata, but Spring Security sends unsigned requests because it falls back to the AP metadata.

OpenSamlMetadataResolver metadataResolver = new OpenSamlMetadataResolver();
metadataResolver.setEntityDescriptorCustomizer(p -> {
    SPSSODescriptor spssoDescriptor = p.getEntityDescriptor().getSPSSODescriptor(SAMLConstants.SAML20P_NS);
    spssoDescriptor.setAuthnRequestsSigned(true);
});
Saml2MetadataFilter filter = new Saml2MetadataFilter(resolver, metadataResolver);

So the problem is I need to lower my security to unsigned requests because that's the default in the IdP.

[RSM-SLU]

In my case our IdP does not send the setting in its metadata. So Spring defaults to not signing requests. According to our system administrators all Java applications sign their requests though, which is configured per app.
Simply setting the flag globally could potentially impact other parties relying on the metadata. So it becomes necessary to overwrite the global setting with a per app setting.
This is essentially a misconfiguration of the IdP, but for large setups it might not be easily possible to change global defaults.

[jzheaux]

It sounds like there may be an issue with how the Spring Boot properties are read as I would imagine that setting the sign-request property to true should override whatever is stated in the metadata response. I've created spring-projects/spring-boot#33747 to investigate before proceeding with any Spring Security changes.