[keycloak-dev] Remaining work for 1.1.0.Final

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 December, 2014 2:01:20 PM
> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
> 
> 
> 
> On 12/17/2014 3:11 AM, Stian Thorgersen wrote:
> >> 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 :/
> >
> 
> If the PL IDM API user is using the default PL IDM API security model,
> then we can write something generic and plug it in via a JNDI reference
> (1).  I don't understand why you are against this Stian.  Its just PL
> IDM API integration.

I don't like the idea of having a 'picketlink' provider. Problem is what happens when we merge the two projects? Also, what happens if we drop PicketLink IDM as a separate project?

Maybe we could call it 'picketlink2-idm' or something like that and not have it available by default. We could then document it as part of a migration from PicketLink to Keycloak documentation.

If we're going to use PicketLink IDM internally that changes it quite a lot, but that also depends on how we end up using it.

I'd say lets leave it for now, then have a discussion in January about how we plan to use PicketLink IDM in the future, and also what migration paths we should provide for existing PicketLink users.

> 
> I don't like #2 at all.  Users should have no knowledge of PL IDM API
> when using our default LDAP provider.  My hope is that our LDAP provider
> becomes sophisticated enough that the user never needs to see any code
> even for the most complex LDAP deployments.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>