4:31 p.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: keycloak-dev(a)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