SAMLController.ConfigurationResolver

Is there a scenario where the custom implementation of ISAMLConfigurationResolver is not called?
I’m facing a situation where it is calling the built-in implementation and not my custom implementation instead.

Here the exception:
ComponentSpace.SAML2.Exceptions.SAMLConfigurationException:
at ComponentSpace.SAML2.Configuration.SAMLConfigurations.GetConfiguration (ComponentSpace.SAML2, Version=4.2.0.0, Culture=neutral, PublicKeyToken=16647a1283418145)
at ComponentSpace.SAML2.Configuration.Resolver.SAMLConfigurationResolver.GetLocalIdentityProviderConfiguration (ComponentSpace.SAML2, Version=4.2.0.0, Culture=neutral, PublicKeyToken=16647a1283418145)
at ComponentSpace.SAML2.InternalSAMLIdentityProvider…ctor (ComponentSpace.SAML2, Version=4.2.0.0, Culture=neutral, PublicKeyToken=16647a1283418145)
at Drips.Web.Portal.Services.WordPressSamlService.WordpressSignOn (Drips.Web.Portal, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null:


it shouldn’t be calling Resolver.SAMLConfigurationResolver.GetLocalIdentityProviderConfiguration, it should be calling my:

SAMLController.ConfigurationResolver = new SamlConfigurationResolver();

internal class SamlConfigurationResolver : ISAMLConfigurationResolver
{
public LocalIdentityProviderConfiguration GetLocalIdentityProviderConfiguration(string configurationID)
{
SAMLConfiguration config = null;
if (string.IsNullOrEmpty(configurationID))
{
config = SAMLController.Configurations.GetConfiguration(SamlService.DefaultServiceConfigurationID);
return config.LocalIdentityProviderConfiguration;
}

config = Getconfiguration(configurationID);
if(config != null)
{
return config.LocalIdentityProviderConfiguration;
}

return SAMLController.Configuration.LocalIdentityProviderConfiguration;
}
}

The SAML SSO API always accesses SAML configuration through the SAMLController.ConfigurationResolver property. It never directly accesses the built-in implementation of ISAMLConfigurationResolver.

There are three different ways to supply SAML configuration.

1. Include a saml.config file. The SAML configuration is loaded into memory, the built-in implementation of ISAMLConfigurationResolver is initialized with this configuration and the SAMLController.ConfigurationResolver property set.

2. Use the SAMLController.Configurations or SAMLController.Configuration property to specify the configuration programmatically. In a similar manner, the built-in implementation of ISAMLConfigurationResolver is initialized with this configuration and the SAMLController.ConfigurationResolver property set.

3. Set the SAMLController.ConfigurationResolver property with a custom implementation of ISAMLConfigurationResolver.

Your implementation of ISAMLConfigurationResolver is accessing the SAMLController.Configurations property. If you accessed the setter for this property it would initialize the built-in implementation of ISAMLConfigurationResolver as outlined in #2 above. If you only accessed the getter it would return an empty SAML configuration.

I’m not sure exactly what’s going on here but your custom implementation of ISAMLConfigurationResolver shouldn’t be attempting to retrieve its configuration from the SAMLController.Configurations or SAMLController.Configuration properties. Instead, it should retrieve it from wherever you’re storing the configuration (eg a custom database).

Also, make sure to set the SAMLController.ConfigurationResolver property once only at application start-up before any of the other SAML APIs are called.

If there’s still an issue, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.

https://www.componentspace.com/Forums/17/Enabing-SAML-Trace

Also, please include your configuration resolver source code.

[quote]
ComponentSpace - 10/12/2023
The SAML SSO API always accesses SAML configuration through the SAMLController.ConfigurationResolver property. It never directly accesses the built-in implementation of ISAMLConfigurationResolver.

There are three different ways to supply SAML configuration.

1. Include a saml.config file. The SAML configuration is loaded into memory, the built-in implementation of ISAMLConfigurationResolver is initialized with this configuration and the SAMLController.ConfigurationResolver property set.

2. Use the SAMLController.Configurations or SAMLController.Configuration property to specify the configuration programmatically. In a similar manner, the built-in implementation of ISAMLConfigurationResolver is initialized with this configuration and the SAMLController.ConfigurationResolver property set.

3. Set the SAMLController.ConfigurationResolver property with a custom implementation of ISAMLConfigurationResolver.

Your implementation of ISAMLConfigurationResolver is accessing the SAMLController.Configurations property. If you accessed the setter for this property it would initialize the built-in implementation of ISAMLConfigurationResolver as outlined in #2 above. If you only accessed the getter it would return an empty SAML configuration.

I'm not sure exactly what's going on here but your custom implementation of ISAMLConfigurationResolver shouldn't be attempting to retrieve its configuration from the SAMLController.Configurations or SAMLController.Configuration properties. Instead, it should retrieve it from wherever you're storing the configuration (eg a custom database).

Also, make sure to set the SAMLController.ConfigurationResolver property once only at application start-up before any of the other SAML APIs are called.

If there's still an issue, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.

https://www.componentspace.com/Forums/17/Enabing-SAML-Trace

Also, please include your configuration resolver source code.
[/quote]

I spotted a place where the SAMLController.Configuration property was been set,
Thanks!

Thanks for the update.