[keycloak-dev] Remaining work for 1.1.0.Final
Bill Burke
bburke at redhat.com
Tue Dec 16 09:55:26 EST 2014
On 12/16/2014 8:55 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, December 16, 2014 11:42:44 AM
>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>
>> On 16.12.2014 13:37, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, 16 December, 2014 1:25:50 PM
>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final
>>>>
>>>> Btw, regarding SAML brokering. I'm trying to focus on KC integration with
>>>> a
>>>> PL SAML IdP. I think that will help people (customers and community)
>>>> already
>>>> using PL to adopt KC without forcing them to drop existing infrastructure
>>>> and investments. And that will also help them to think about a migration
>>>> plan.
>>> 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).
>
> [1] http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Stereotypes
>
There would still need to be code to map from the user's "stereotype" to
the Keycloak metamodel.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list