[Feature] Allow configuration of AssertionConsumerService Bindings in SP Metadata

[f-kanari]

Summary

The current implementation of the Metadata() function automatically includes two AssertionConsumerService endpoints in the generated SP metadata: HTTP-POST Binding and HTTP-Artifact Binding. How about allowing configuration of AssertionConsumerService Bindings in SP Metadata?

saml/service_provider.go

Lines 256 to 268 in 3465403

	AssertionConsumerServices: []IndexedEndpoint{
	{
	Binding: HTTPPostBinding,
	Location: sp.AcsURL.String(),
	Index: 1,
	},
	{
	Binding: HTTPArtifactBinding,
	Location: sp.AcsURL.String(),
	Index: 2,
	},
	},
	},

Problem / Motivation

HTTP-POST Binding and HTTP-Artifact Binding are two distinct SAML assertion delivery methods. The implementation requirements for these two bindings vary significantly:

1. HTTP-Artifact Binding requires the Service Provider (SP) to implement an Artifact Resolution Service (ARS), which is a complex back-channel communication (usually SOAP) with the Identity Provider (IdP).
2. Many SPs may only intend to support the simpler HTTP-POST Binding.
3. Including unsupported bindings in the metadata is contrary to the SAML specification, as it informs the IdP that the SP is capable of receiving responses via that method. If an IdP chooses the Artifact binding, the authentication flow will fail unless ARS is fully implemented.

When a user only wants to support HTTP-POST, they are currently forced to perform an ad-hoc manual modification of the generated metadata XML to remove the unwanted Artifact Binding entry.

Suggestion

To enhance flexibility and compliance with the principle of only advertising services that are actually supported, I propose adding an option to the ServiceProvider configuration to explicitly specify the list of supported AssertionConsumerService bindings.

This could be implemented using the functional options pattern (e.g., within saml.Options for NewServiceProvider), perhaps with a new field like SupportedBindings:

// Example of the desired configuration structure:
sp, err := saml.NewServiceProvider(saml.Options{
    // New option to specify supported bindings
    SupportedBindings: []saml.BindingType{
        saml.HTTPPostBinding,
        // saml.HTTPArtifactBinding, // Artifact is only included if explicitly listed
    },
})

By making the inclusion of Artifact Binding opt-in, the library can ensure that the generated metadata accurately reflects the SP's capabilities, leading to more robust and specification-compliant federated identity deployments.