<div dir="ltr"><div>There is not problem! :)</div><div>One more thing, I solved the problem of multiple "federation provider" instances, adding this code to the DefaultKeycloakSession (and the method definition in KeycloakSession interface):</div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">public <T extends Provider> void registerProvider(Class<T> clazz, Provider provider, String id) {<br> Integer hash = clazz.hashCode() + id.hashCode();<br> providers.put(hash, provider);<br> }</blockquote><div><br>And into MyUserFederationProviderFactory.getInstance(session, model) something like this:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">public UserFederationProvider getInstance(KeycloakSession session, UserFederationProviderModel model){<br><span class="" style="white-space:pre"> </span>UserFederationProvider provider = (UserFederationProvider) session.getProvider(UserFederationProvider.class, model.getId());<br><span class="" style="white-space:pre"> </span>if (provider == null){<br><span class="" style="white-space:pre"> </span>lazyInit(session);<br><span class="" style="white-space:pre"> </span> provider = new MyUserFederationProvider(session, model, config, ......);<br><span class="" style="white-space:pre"> </span> ((KeycloakSession)session).registerProvider(UserFederationProvider.class, provider, model.getId());<br><span class="" style="white-space:pre"> </span>};<br> return provider;<br> }</blockquote><br>After a few tests and debug it seems to work... creating, catching, and closing provider instances as expected.</div><div><br></div><div><br></div><div><div>In future versions as you said, maybe would be better include a way to instantiate a complex object/provider instead of doing</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">ProviderFactory.create(KeycloakSession session) <br>some kind of method like<br>ProviderFactory.create(KeycloakSession session, Object... obj);</blockquote><div>and the appropriate method into the KeycloakSession</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><T extends Provider> T getProvider(Class<T> clazz, Object... obj);<br><T extends Provider> T getProvider(Class<T> clazz, String id, Object... obj);</blockquote><div><br></div><div>And why not a map into the keycloakSession to store some additional context data to share between providers during same request? It's only a vague idea</div></div><div><br></div><div>Regards!</div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-09 17:14 GMT-03:00 Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Its gonna be awhile. Its going to be difficult to make
everything both backward compatible and cover all the current and
future use cases we need to cover. Listen on the dev list. I
should post some info soon on what the new impl will look like.<br>
</p><div><div class="h5">
<br>
<div>On 6/9/16 3:57 PM, Ariel Carrera wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Yes Bill, exactly! I will waiting to test it
Thanks!<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-06-09 16:29 GMT-03:00 Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
<br>
On 6/9/16 2:52 PM, Ariel Carrera wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hi Bill, is a little expensive for me because I am
creating a new entity manager to connect with a legacy
database, and creating/enlisting a transaction per
instance.<br>
For example in a simple flow case where a user needs to
click "I forgot my password" link to recover the
password, there is more than nine or ten instances
created to do this. It's really not a big problem but I
think that is not necessary and can be implemented like
others spi providers catched into the keycloak session.<br>
<br>
</blockquote>
</span>
This is good feedback. We need a way to associate a
provider, by name, to the KeycloakSession. Maybe we just
need a way to associate anything with the KeycloakSession
period.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
In my case, another difficulty is synchronization
between an old authentication system and keycloak
implemented on demand (there is no full/partial
syncrhonization because the legacy system is still
working and need to work together for a while). Also I
implemented synchronization support but at this moment
it not used.<br>
Every time that keycloak needs to validate a user
(isValid) recovered from the user storage or cache, a
query to the legacy system is made. Added to this... I
need to recover some attributes and roles changes
produced on the legacy system.... so I decided to
implement a "user federation cache" with a short term
expiration to improve the performance with certain
synchronization delay tolerance.<br>
<br>
In a few words I have: a custom User Federation Provider
+ on deman synchronization + a user Federation Provider
Cache (my own cache SPI).<br>
<br>
Maybe an optional spi to obtain a custom container from
infinispan could be a good choice to add to the new
implementation and provide another one tool to do things
with better performance.<br>
<br>
</blockquote>
</span>
I think the new model might solve your caching needs. There
will be no importing by default. This means no synching,
etc. Keycloak will only store metadata that your user store
can't provide. User Federation Providers will work just as
the default Keycloak user store and user cache.<br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div data-smartmail="gmail_signature">Tatú</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Tatú</div>
</div></div></div>