Re: [keycloak-dev] Remaining work for 1.1.0.Final

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "Pedro Igor Silva" <psilva(a)redhat.com&gt;, "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, 16 December, 2014 6:15:30 PM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final On 16.12.2014 15:27, Stian Thorgersen wrote: >>>>> Makes sense. We should also provide a migration path for the stored >>>>> > >>>users. >>>>> > >>>If we moved to PL IDM that'd be easy, but not sure that'll happen >>>>> > >>>straight >>>>> > >>>away. Maybe we could provide a PL IDM user federation provider? >>>> > >>Well, we defacto already have it:) Our LDAPFederationProvider is >>>> > >>using >>>> > >>Picketlink IDM API to bridge between keycloak model and >>>> > >>org.picketlink.idm.model.basic.User . There is no direct interaction >>>> > >>with LDAP, but everything goes through PL IDM API. >>>> > >> >>>> > >>In early stage when we discussed ldap integration and using PL IDM >>>> > >>API >>>> > >>for it, we also discussed that it could be nice if people could >>>> > >>provide >>>> > >>different source of PL IDM store. So there is >>>> > >>PartitionManagerProvider >>>> > >>interface, which provides access to pl idm PartitionManager. Right >>>> > >>now >>>> > >>we have just one implementation LDAPPartitionManagerProvider, which >>>> > >>returns picketlink PartitionManager configured to use LDAP store >>>> > >>based >>>> > >>on ldap configuration provided by keycloak admin console. >>>> > >> >>>> > >>So theoretically only thing, which people need to do is to provide >>>> > >>their >>>> > >>own PartitionManagerProvider when they can configure PL IDM stores >>>> > >>according to their environment. And this PartitionManagerProvider >>>> > >>would >>>> > >>need to be configured in keycloak-server.json, so it has precedence >>>> > >>over >>>> > >>the default LDAP based impl. Only condition is that their users >>>> > >>should >>>> > >>be retrievable with usage of org.picketlink.idm.model.basic.User >>>> > >>from PL >>>> > >>IDM Basic model. >>> > >Or they can just provide a JNDI url where the PartitionManager is >>> > >located, >>> > >when using the subsystem. Also, PL IDM has the concept of stereotypes >>> > >[1]. >>> > >What means, in theory, that you can deal with any identity model >>> > >definition (eg.: not only the basic identity model). >> >yeah, so we can do something like "SubsystemPartitionManagerProvider", >> >which will allow people to retrieve PartitionManager from JNDI URL and >> >they won't need to code anything by themselves. Only provide JDNI URL in >> >configuration. > What about following the same pattern as we use for JPA and Infinispan. The > default provider can either be configured to create on on it's own or you > can set the data-source / jndi-name? > Yeah, that should work well. Tricky thing is how to configure it in admin console? Right now we have 'ldap' federation provider, which allows to configure ldap settings and this is the provider, which delegates to picketlink. So possible solution is: 1) Add another provider in admin console. So they will be both 'ldap' and 'picketlink' providers available. In the screen for 'ldap' provider, people can configure LDAP like it's now. In the screen for 'picketlink' provider, people can configure just JNDI URL from where they can retrieve PartitionManager from picketlink subsystem. Implementation wise, we can have 2 implementations of UserFederationProviderFactory, which will differ just in the detail on how to retrieve PartitionManager - https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main... . The 'ldap' impl can call: session.getProvider(PartitionManagerProvider.class, 'ldap') to retrieve LDAPPartitionManagerProvider. The 'picketlink' impl can call: session.getProvider(PartitionManagerProvider.class, 'picketlink') to retrieve SubsystemPartitionManagerProvider (or PicketlinkPartitionManagerProvider ?), which will retrieve PartitionManager from configured JNDI URL. 2) Have single impl of UserFederationProvider and in admin console, there may be checkbox. If checked, people can configure JNDI URL. If not checked, people can configure LDAP like it's now. I like (1) more. Solution (2) make it a bit harder to enable LDAP integration. Better ideas?

Marek