public <T extends Provider> void registerProvider(Class<T> clazz, Provider provider, String id) {
Integer hash = clazz.hashCode() + id.hashCode();
providers.put(hash, provider);
}
public UserFederationProvider getInstance(KeycloakSession session, UserFederationProviderModel model){
UserFederationProvider provider = (UserFederationProvider) session.getProvider(UserFederationProvider.class, model.getId());
if (provider == null){
lazyInit(session);
provider = new MyUserFederationProvider(session, model, config, ......);
((KeycloakSession)session).registerProvider(UserFederationProvider.class, provider, model.getId());
};
return provider;
}
ProviderFactory.create(KeycloakSession session)
some kind of method like
ProviderFactory.create(KeycloakSession session, Object... obj);
<T extends Provider> T getProvider(Class<T> clazz, Object... obj);
<T extends Provider> T getProvider(Class<T> clazz, String id, Object... obj);
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.
On 6/9/16 3:57 PM, Ariel Carrera wrote:
Yes Bill, exactly! I will waiting to test it Thanks!
2016-06-09 16:29 GMT-03:00 Bill Burke <bburke@redhat.com>:
On 6/9/16 2:52 PM, Ariel Carrera wrote:
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.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.
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.
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.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.
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.
In a few words I have: a custom User Federation Provider + on deman synchronization + a user Federation Provider Cache (my own cache SPI).
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.
--
Tatú