[keycloak-dev] Remaining work for 1.1.0.Final

[Pedro Igor Silva]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at 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 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.

Yeah, true. The idea behind those stereotypes is that PL provides some built-in features that require some very specific info to integrate any identity model with them. For instance, authorization based on RBAC and GBAC. So you can just plug your identity model and get things working without having to deal with SPIs.

> 
> Bill
> 
> --
> 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
>