SAML metadata specifies `WantAuthnRequestsSigned` incorrectly

[voidmain]

Description

If you enable SAML under an Application, the metadata.xml for that Application incorrectly specifies the WantAuthnRequestsSigned attribute on the <IDPSSODescriptor> element. This value should be false if the SAML configuration has the application.samlv2Configuration.logout.requireSignedRequests flag set to false. It is always set to true no matter the configuration, which makes the metadata.xml unusable for SPs that don't support signed requests (like AWS IAM).

Affects versions

1.34.1

Steps to reproduce

Steps to reproduce the behavior:

1. Create an Application and enable SAML
2. View the Application details and copy and paste the SAML metadata URL into a browser
3. See the incorrect flag

[robotdan]

The URL to consume the IDP Metadata is /samlv2/metadata/{tenantId}.

So the meta data is tenant wide, and the signing configuration is per application, so we currently just set this value equal to true knowing that it may not be correct.

We actually have two separate application configurations for signing, one for AuthN requests, and the other for Logout requests.

• application.samlv2Configuration.requireSignedRequests
• application.samlv2Configuration.logout.requireSignedRequests

In order to set this value correctly, we'd need to either optionally take the applicationId on this URL, or require it.

[robotdan]

We could optionally allow this endpoint to be called like this:

/samlv2/metadata/{tenantId}/{applicationId}

If we did this, we could have enough context to to set WantAuthnRequestsSigned correctly.

Other IdPs may always set this to false.

• https://support.okta.com/help/s/question/0D51Y000063EkpOSAS/how-to-set-wantauthnrequestssignedtrue-saml-app?language=en_US
• https://support.okta.com/help/s/article/Can-the-WantAuthnRequestsSigned-value-be-set-to-True?language=en_US

So another option is to hard code this to false - which would also not always be correct, but perhaps this is more accepted by SPs.

[agertenbach]

Does FusionAuth accept an unsigned request despite the presence of this flag being set to true?

If it will accept an unsigned request regardless, you can likely set this to false or emit the parameter completely. This flag is optional, and is an indicator to service providers that an unsigned request may be rejected by the identity provider. Both the identity provider and service provider may opt to ignore this.

See OASIS docs: https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf (line 687) http://docs.oasis-open.org/security/saml/v2.0/sstc-saml-approved-errata-2.0.pdf (line 116)

If a signed request is required by and subsequently validated by FusionAuth, implementation of the metadata endpoint as described with an application ID in the route is reasonable, and is similar to the approach used by other identity providers (Okta, Auth0)

[agertenbach]

Example SP library implementation -- Sustainsys for .NET can be set to sign always, sign never, or follow the behavior requested by the IdP. It will throw an exception if the IdP has requested signature but a signing cert for the SP is not available:

https://saml2.sustainsys.com/en/v2/config-elements/sustainsys-saml2.html#attributes