[keycloak-dev] LDAP integration

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 March, 2014 3:21:08 PM
> Subject: Re: [keycloak-dev] LDAP integration
> 
> 
> 
> On 3/14/2014 11:15 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 14 March, 2014 2:12:20 PM
> >> Subject: Re: [keycloak-dev] LDAP integration
> >>
> >> Don't we need to have LDAP as a user store?  Won't companies have a user
> >> LDAP store they want to point Keycloak to?  If you have an Auth SPI
> >> only, then you'll still need to register the users with Keycloak.
> >
> > The idea with the authentication would be similar to social login. On first
> > login a user would be created internally in Keycloak, and there would be a
> > link to the user in LDAP. It would provide us with something relatively
> > simple without the fuzz. Social login requires registration to be enabled
> > for new users, but that shouldn't be required to create users that "links"
> > to an LDAP store.
> >
> > We can even investigate allowing multiple authentication providers for a
> > single realm. For example if a user exist in Keycloak you can check if
> > there is a LDAP link, if there is authenticate with LDAP, otherwise with
> > Keycloak. If no user exist, check with the other configured authentication
> > providers if one exists.
> >
> > In the second round we can worry about syncing, or alternatively by using
> > LDAP directly for users/role-mappings. I'm not 100% convinced, but I
> > believe the syncing approach is the simpler and probably better solution
> > to "federation".
> >
> 
> So, all user updates (password, attributes, otp, etc...) will be stored
> in Keycloak and then synced with LDAP?

Can be yes, the Sync SPI needs to be flexible enough to specify what should be synced. It may also only be a one-way sync. Some examples:

* Full sync with LDAP - if a user is added/changed in Keycloak it will be updated in LDAP, same other way around. This includes everything we can sensibly store in LDAP. It will also sync role mappings.
* Read only sync with LDAP - for whatever reason the admin doesn't want to let Keycloak write back to the LDAP server. In this case we'd read changes from LDAP, but not write changes back.
* Write only of users - for example if an application wants to have user profiles (excluding passwords, otp, etc.) in a relational database that can be queried directly by the application. This can be done by implementing the Sync SPI, and they can obviously change the way a user is represented by transforming it during the sync.

This is most likely a stupid idea, but could we use the same syncing solution to sync between a cache and the db?!?

> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>