[keycloak-dev] User Federation provider instances

Stian Thorgersen sthorger at redhat.com
Fri Apr 29 04:22:09 EDT 2016


We have 3 types of providers:

* Server configured - no config or config from keycloak-server
* Realm configured - config from realm model
* Instance configured - multiple instances per realm

Removing master realm as we plan to do means that realm configured provider
factories can get realm from KeycloakContext as there's only one realm
per-session.

For instance configured I propose we add getProvider(Class c, String id,
String instanceId) to provider factory. The it's up to the provider factory
itself to extract  the config from the realm model or another source. It
also means that the session can easily keep track of these and only create
one id+instanceId per session.
On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com> wrote:

Yes, AFAIK we have open JIRA for this for a long time ago.

It's the same issue for IdentityProvider (and maybe some others SPI too)
that they bypass "official" way for create provider via
session.getProvider(providerClazz) and hence they are not registered in
KeycloakSession and "close" method is not called for them.

The issue is that our SPI is a bit limited IMO and doesn't support
"stateful" providers. The providers are created through
"ProviderFactory.create(KeycloakSession)". So the only available state of
provider ATM is just ProviderFactory + KeycloakSession, which is sometimes
not sufficient.


I can see 2 possibilities to address:

1) Always make the provider implementation "stateless" and ensure all the
state is passed as argument to provider methods. This is what we already do
for some providers (for example all methods of UserProvider has RealmModel
as parameter). So if we rewrite UserFederation SPI that
UserFederationProviderModel will be passed as argument to all methods of
UserFederationProvider, then it can use "official" way too.


2) Improve the SPI, so it can properly support "stateful" providers. This
is more flexible then (1) and I would go this way long term.

I am thinking about something like this:

public interface StatefulProvider<S> extends Provider {
}


public class StatefulProviderFactory<T extends StatefulProvider, S> {

     T create(KeycloakSession session, S state);

     .......
}


and on KEycloakSession new method like this:

<S, T extends StatefulProvider<S>> T getProvider(Class<T>
providerClazz, String id, S state);


The "state" will need to properly implement equals and hashCode, so the SPI
can deal with it and not create another instance of StatefulProvider if it
was called for this KeycloakSession with same state before.

Marek



On 29/04/16 08:00, Stian Thorgersen wrote:

Looking at the code for user federation it looks like user federation
provider instances with the same configuration can be created multiple
times for a single session. Also they are never closed to resources aren't
released.


_______________________________________________
keycloak-dev mailing
listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/61311577/attachment.html 


More information about the keycloak-dev mailing list