<div dir="ltr">Currently it&#39;s expected that the factory is application scoped, while provider instances are request scoped. Factories can if they want return the same instance for provider to make it application scoped.<div><br></div><div>This works as long as config is server-wide, but not if there are config per-realm or even multiple different instances per-realm. This applies to for example User Federation SPI (multiple per-realm), Password Hashing SPI (one per-realm), etc.</div><div><br></div><div>Currently the User Federation SPI creates and manages instances outside of the session factory and session, which results in multiple instances created per-request, not all being closed properly, etc..</div><div><br></div><div>With that in mind I&#39;d like to change the provider factories so that there can be multiple provider factory instances. It&#39;s not completely figured out, but I wanted to discuss it before I start a POC around it.</div><div><br></div><div>We&#39;d have the following methods on KeycloakSession:</div><div><br></div><div>* getProvider(Class&lt;T&gt; clazz, Provider.class) - returns default provider<br></div><div>* getProvider(Class&lt;T&gt; clazz, Provider.class, String providerId) - returns a specific provider, with the default config<br></div><div>* getProvider(Class&lt;T&gt; clazz, Provider.class, String providerId, String instanceId) - returns a specific provider, with the specific config<br></div><div><br></div><div>We&#39;d also add a method:</div><div><br></div><div>* invalidateProvider(Class&lt;T&gt; clazz, Provider.class, String providerId, String instanceId) - this would be called when the config for a specific provider instance is updated</div><div><br></div><div>Behind the covers the instances would be maintained. Each provider factory would internally be responsible to retrieve config and cache config for instances.</div><div><br></div><div>Does this sound like an idea worth pursuing? I&#39;d like to try it out on the PasswordPolicy SPI first.</div></div>