Hello,
We’ve been using configurations to store partner IdP information, but for scalability reasons we are looking to move to the database. We could find a migration SQL script which contains the code for the tables and indexes, and we could inherit from SamlConfigurationContext and overriding AbstractSamlConfigurationResolver like in the example and it would work. The issue is that:
- we don’t necessarily need all the tables in the script (we only plan to use Certificats and the Partner Idp ones)
- we were not able to change the table names or move to a different schema
Are we doing anything wrong? Is there a way around it?
The recommended approach is to implement the ISamlConfigurationResolver interface by extending the AbstractSamlConfigurationResolver class.
We place no limitations on how your implementation stores and retrieves SAML configuration. It can be stored in a custom database etc.
I’m not sure which script you’re referring to. We include a SamlConfigurationDatabase extension which implements ISamlConfigurationResolver and stores configuration in an Entity Framework database. There are migration scripts for this. However, there’s no requirement to use this extension.
The ExampleServiceProvider and ExampleIdentityProvider projects under the Examples\SSO folder both include a ConfigurationExamples class with an implementation of ISamlConfigurationResolver that uses hard-coded values for simplicity. Your implementation would instead retrieve the configuration from your custom database.
1 Like
Thanks, acting directly on the interface level allowed us to specify our schema and table names/structure