[keycloak-dev] Remaining work for 1.1.0.Final

[Marek Posolda]

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?

Marek