<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">+1 on having "invalidateProvider"
method.<br>
<br>
For the other stuff, we already have the first 2 "getProvider"
methods, so the new stuff will be the methods with "String
instanceId" parameter, right?<br>
<br>
We already discuss adding the "String instanceId" . Now when
thinking more, it looks that it is not so convenient. <br>
<br>
When adding again UserFederation SPI as an example:<br>
<br>
- UserFederationProviderFactory needs UserFederationProviderModel
to create instance of UserFederationProvider<br>
- So factory needs to lookup model from cache/db. Hence the
instanceId would need to be compound of something like:
<REALM-UUID>::<USER-FEDERATION-PROVIDER-MODEL-ID><br>
That's because to lookup UserFederationProviderModel, you first
need RealmModel and then find the UserFederationProviderModel by
it's ID within the realm.<br>
<br>
You may admit that RealmModel is available on KeycloakContext.
However I don't think that we can rely on it. KeycloakContext is
available in REST requests, but in some other cases (ie.
ExportImport, periodic tasks etc), it's not available. Caller
usually have the RealmModel and he can manually set it to
KeycloakContext before calling session.getProvider, however that
doesn't look like good approach to me and should be rather
avoided. So in shortcut, we shouldn't rely on realm being
available in KeycloakContext IMO. <br>
<br>
The logic for parse the "instanceId" and retrieve
UserFederationProviderModel from DB would be boilerplate code same
to all UserFederationProviderFactory impls.<br>
<br>
<br>
With that in mind, it really seems to me that instead of "String
instanceId", it may work better to have some common configuration
class like "ProviderModel" . Then signature will look like: <br>
<br>
* getProvider(Class<T> clazz, String providerId,
ProviderModel model)<br>
<br>
All the model subclasses (UserFederationProviderModel,
IdentityProviderModel, PasswordPolicyModel ...) will be subclasses
of ProviderModel<br>
<br>
Marek<br>
<br>
On 23/06/16 12:01, Stian Thorgersen wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAfb1zoc1VkTg6MFAAp8g-LXjhNNi_Wxf834NVLxzSZEjg@mail.gmail.com"
type="cite">
<div dir="ltr">Currently it'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'd like to change the provider factories
so that there can be multiple provider factory instances. It's
not completely figured out, but I wanted to discuss it before
I start a POC around it.</div>
<div><br>
</div>
<div>We'd have the following methods on KeycloakSession:</div>
<div><br>
</div>
<div>* getProvider(Class<T> clazz, Provider.class) -
returns default provider<br>
</div>
<div>* getProvider(Class<T> clazz, Provider.class, String
providerId) - returns a specific provider, with the default
config<br>
</div>
<div>* getProvider(Class<T> clazz, Provider.class, String
providerId, String instanceId) - returns a specific provider,
with the specific config<br>
</div>
<div><br>
</div>
<div>We'd also add a method:</div>
<div><br>
</div>
<div>* invalidateProvider(Class<T> 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'd like to
try it out on the PasswordPolicy SPI first.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>