Reading IdP metadata xml programmatically and initiating SSO from SP

SAML for ASP.NET Core
1

Hello,

We have many customers and each customer provides us IdP metadata XML file URL which we store in database for each customer (tenant). Now to initiate the SSO, we want to load the XML file URL from database and download this file to a string and then initiate the SSO from SP. Couldn’t figure out how to load XML metadata.

public async Task<IActionResult> InitiateSingleSignOn(string returnUrl = null)
{ // download and parse XML, and pass xml to ssoDescriptor
IdpSsoDescriptor ssoDescriptor = new IdpSsoDescriptor(xmlElement);
_identityProviderMetadataImporter.Import(ssoDescriptor);
// now how to get the partner name for this IdP
await _samlServiceProvider.InitiateSsoAsync(partnerName, returnUrl);

return new EmptyResult();
}

2

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-Guide

An 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.

3

Hi,

Thanks for the detailed answer. We have actually decided to use XML metadata file to load the SAML configuration. Even if customer provides details through email, form etc. we generate an XML for the same and store that in the database for each tenant.

Now our app runs in a web farm environment. Loading the configuration from ISamlConfigurationResolver at the time of startup is not enough as many SAML xmlss can be added later on by some tenants. It seems once configuration is loaded it resides in memory, but that may not work in our case (in web farm environment) where SAML configs can be added/removed dynamically.

So we have to load the xml metadata always from database, convert it to configuration before initiating the SSO or in the ACS endpoint. In initiate-sso and acs endpoints I tried following to load the config dynamically, but I am not sure if it is correct:

XmlDocument xmlDocument = new XmlDocument();
xmldocument.LoadXml(tenant.SamlIdpMetadata);
var samlConfigurations = _samlMetadataToConfiguraton.Import(xmldocument.DocumentElement);
var samlConfiguration = samlConfigurations.Configurations.FirstOrDefault();
samlConfiguration.ID = tenant.Id;
await _samlServiceProvider.SetConfigurationIDAsync(tenant.Id);
await _samlServiceProvider.InitiateSsoAsync(null, returnUrl); return new EmptyResult();

4

Configuration isn’t loaded once at start-up when using the ISamlConfigurationResolver interface. We call into this interface whenever configuration is required (eg to initiate SSO, to receive SSO etc). This means that we will pick up any new configuration or configuration changes immediately. Your implementation would access the configuration in your database. The ISamlConfigurationResolver interface is the recommended approach for dynamic SAML configurations.

Please refer to the “Implementing ISamlConfigurationResolver” section of the Configuration Guide for more information.

https://www.componentspace.com/Forums/8234/Configuration-Guide