Currently we don't support direct consumption of SAML metadata. Instead, SAML metadata may be imported to create SAML configuration which is then used by the SAML API. There are a number of reasons for this.
In some use cases, SAML metadata isn't available or used. For example, customers may supply their configuration by answering a few questions or updating a web form with the configuration then stored in a database.
SAML metadata's purpose is to exchange configuration information between partner providers. However, it isn't necessarily the most efficient or complete format when implementing SAML SSO. For example, certificates are embedded as base-64 strings in metadata. SAML configuration supports many different storage options for certificates (eg strings, files, Windows certificate store, Azure key fault).
There are performance considerations when downloading SAML metadata. This can be mitigated through caching etc but this adds a degree of complexity.
Also, there are security considerations in automatically using SAML metadata without any human intervention. If an attacker were able to replace the metadata at a URL, this would open the entire system up to attack. There are steps that can be taken to minimize this risk but it's still a consideration.
Having said this, it is possible to implement configuration directly through SAML metadata using our ISamlConfigurationResolver interface. This interface is described in our Configuration Guide.
https://www.componentspace.com/Forums/8234/Configuration-GuideAn ISamlConfigurationResolver could access a database of URLs, download metadata as required, and return requested configuration from this metadata.
We've considered providing an implementation that directly uses SAML Metadata but have baulked at doing so primarily because of the security concerns.
Regards
ComponentSpace Development