When overriding AbstractSamlConfigurationResolver, configurationId parameter value is null.

SAML for ASP.NET Core
1

Howdy,

I am implementing an override of the AbstractSamlConfigurationResolver class called CustomerSamlConfigurationResolver. I have a custom assertion endpoint for my local service provider. This custom assertion endpoint follows the examples given by ComponentSpace exactly for now. It is pasted at the bottom of this post.

My question is whenever the method GetLocalServiceProviderConfigurationAsync(string configurationId) of my CustomerSamlConfigurationResolver : AbstractSamlConfigurationResolver is called the configurationId paramter is null. This method gets called as part of the ReceiveSsoAsync() method. I must have configured something incorrectly for this to correct but I am not sure what?

My configuration is done programatically and I only setup a local service provider

Configuration Code:
private void ConfigureComponentSpaceSaml(SamlConfigurations samlConfigurations)
{
samlConfigurations.Configurations = new List()
{
new SamlConfiguration()
{
LocalServiceProviderConfiguration = new LocalServiceProviderConfiguration()
{
Name = “Identity Service Provider”,
Description = “Identity Service Provider”,
AssertionConsumerServiceUrl = "<a href=“http://localhost:3600/Saml2/Acs",">http://localhost:3600/Saml2/Acs”,
SingleLogoutServiceUrl = “<a href=“http://localhost:3600/Saml2/SingleLogoutService",">http://localhost:3600/Saml2/SingleLogoutService”,
ArtifactResolutionServiceUrl = “<a href=“http://localhost:3600/Saml2/ArtifactResolutionService",">http://localhost:3600/Saml2/ArtifactResolutionService”,
}
}
};
}

Assertion Endpoint Code:
public async Task ACS()
{
// Receive and process the SAML assertion contained in the SAML response.
// The SAML response is received either as part of IdP-initiated or SP-initiated SSO.
var ssoResult = await _samlServiceProvider.ReceiveSsoAsync();

// Automatically provision the user.
// If the user doesn’t exist locally then create the user.
// Automatic provisioning is an optional step.
var user = await _userManager.FindByNameAsync(ssoResult.UserID);

// Automatically login using the asserted identity.
await _signInManager.SignInAsync(user, isPersistent: false);

// Redirect to the target URL if specified.
if (!string.IsNullOrEmpty(ssoResult.RelayState))
{
return LocalRedirect(ssoResult.RelayState);
}

return RedirectToPage(”/Index”);
}




2

The configurationID parameter is only required if you’re supporting multiple SAML configurations. Typically this is the case in a multi-tenanted environment where each tenant has their own separate SAML configuration.

If there are multiple SAML configurations, ISamlProvider.SetConfigurationIDAsync must be called prior to any other SAML API call to specify which SAML configuration to use when processing the SSO/SLO flow. If this is done, the configurationID parameter will be set to the value specified by SetConfigurationIDAsync.

In the typical use there’s a single SAML configuration in which case the configurationID parameter will be null.

Just to be clear, as the SP a SAML configuration consists of the SP configuration and one or more partner IdP configurations. You don’t need multiple SAML configurations to support multiple partner IdPs.

3
[quote]
ComponentSpace - 5/7/2020
The configurationID parameter is only required if you're supporting multiple SAML configurations. Typically this is the case in a multi-tenanted environment where each tenant has their own separate SAML configuration.

If there are multiple SAML configurations, ISamlProvider.SetConfigurationIDAsync must be called prior to any other SAML API call to specify which SAML configuration to use when processing the SSO/SLO flow. If this is done, the configurationID parameter will be set to the value specified by SetConfigurationIDAsync.

In the typical use there's a single SAML configuration in which case the configurationID parameter will be null.

Just to be clear, as the SP a SAML configuration consists of the SP configuration and one or more partner IdP configurations. You don't need multiple SAML configurations to support multiple partner IdPs.
[/quote]

Thanks so much for your help. Two Follow up questions.

1) My understanding is that if I override the AbstractConfigurationResolver, that I will not need to set up any configuration in StartUp.cs because all of the configuration is retrieved from this class, whenever it is needed.

2) I was wondering if the service provider as middle ware can be used along with overriding the AbstractConfigurationResolver?

Again, thanks for your help.
4
  1. That’s correct. There are various options for setting up SAML configuration including specifying it in appsettings.json, programmatically at application start-up, or by implementing the ISamlConfigurationResolver interface. These options are outlined in our Configuration Guide.

    2. Yes. Overriding the AbstractConfigurationResolver supports both models (ie calling the SAML API and using the SAML middleware).