Re: [keycloak-dev] Remaining work for 1.1.0.Final

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, December 16, 2014 12:55:26 PM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final On 12/16/2014 8:55 AM, Pedro Igor Silva wrote: > ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Pedro Igor Silva" >> <psilva(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> 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(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>> 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-Ste... > 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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev