Hi Florin, The recommended approach is to implement the ISamlConfigurationResolver interface as described in the Configuration Guide. https://www.componentspace.com/Forums/8234/Configuration-GuideThe section "SAML Configuration Options" outlines the alternatives and recommendations for when to use each approach. The section "Implementing ISamlConfigurationResolver" describes this interface and includes a couple of example implementations. You would store your SAML configuration in a custom database. Your implementation of ISamlConfigurationResolver would retrieve information from this database as requested. Configuration is requested on demand as part of a SAML SSO or SLO flow. Note that the current version of the documentation suggests using services.TryAddScoped to specify your implementation. This requires you to do this prior to calling services.AddSaml otherwise the default ISamlConfigurationResolver implementation that reads from appsettings.json is still active. A better approach is to call services.AddScoped<ISamlConfigurationResolver, YourSamlConfigurationResolver>(); Regarding the approach you tried, you can specify the SamlConfigurations programmatically. If you take a look at the ExampleIdentityProvider and ExampleServiceProvider projects we ship, their Startup classes include a ConfigureSaml method. Instead of calling services.AddSaml(Configuration.GetSection("SAML")), which adds the SAML configuration from the appsettinsg.json, you would call services.AddSaml(config => ConfigureSaml(config)). However, I think for your scenario it's better to implement ISamlConfigurationResolver.
Regards ComponentSpace Development
|