[keycloak-dev] Remaining work for 1.1.0.Final

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> 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/java/org/keycloak/federation/ldap/LDAPFederationProviderFactory.java#L46
> .
> 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?

Hm.... I don't like either of those, but don't have any better ideas :/

> 
> Marek
>