7:13 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)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...
>> .
>> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev