Can the 'WantAuthNRequestsSigned' value be changed in the SAML Metadata.xml file?

Version Affected:  All

Description:  
Can the 'WantAuthNRequestsSigned' value be changed in the SAML Metadata.xml file via config changes to the Realm in question?

Cause:  
Some Service Providers require this value in the Metadata.xml file to be set to a specific value (true/false)
Unfortunately, this is not working as expected within IdP/Identity Platform at present:

If the Realm is a 'Classic' Realm
When downloading the Metadata.xml file from Advanced Settings, this value is generated to be set at '0', there are no changes within the Realm config which will alter this outcome as it is hardcoded to always be set at '0'.

If the Realm is a New Experience Realm
When downloading the Metadata.xml file from Advanced Settings, the same comments as above will apply.
When downloading the Metadata.xml file from New Experience interface, the 'WantAuthNRequestsSigned' value is assigned a value of 'true' if the configuration setting 'Sign SAML Assertion' is set to 'True' within the New Experience interface.
If 'Sign SAML Assertion' is set to 'False', the 'WantAuthNRequestsSigned' value will be set to 'false' in the Metadata.xml file when downloaded.
This is incorrect, the 'WantAuthNRequestsSigned' should not be reliant on the Identity Appliance signing the SAML Assertion or not and should be independently configurable.

Resolution:  
This is a confirmed bug (EE-3582) in the Product and will be addressed with a future release.
As a workaround, until the fix is in place, the Metadata.xml file can be manually altered to reflect the requirements of the Service Provider.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.