[keycloak-user] To LDAP or NOT?

Marek Posolda mposolda at redhat.com
Mon Dec 28 17:18:24 EST 2015


On 22/12/15 21:09, Christopher Wallace wrote:
> Thanks for the Insight Marek, Since we are building newer applications 
> and have no LEGACY application that require LDAP, I think it's clear 
> for us to store our users in KEYCLOAK and use SAML or OpenID protocol 
> for Identity Management Interoperability. If we to inherit some LEGACY 
> applications in the future we can the point our KEYCLOAK server at 
> those repository and have KEYCLOAK be the Single Source. Sound reasonable?
Yes.

Just one thing. Currently we don't have support for bulk sync of users 
from Keycloak to LDAP.

We have support for sync newly created/registered users to LDAP when the 
flow is like:
- You create LDAP federation provider in Keycloak admin console
- You register user "john" in Keycloak
- This user will be registered in both Keycloak DB and LDAP

But we don't have support for sync of previously created users to 
Keycloak, when the flow is like:
- You register new user "john" and he will be created just in Keycloak 
DB (because LDAP federation provider is not yet created)
- Then you create LDAP federation provider
- There is not supported to link Keycloak user "john" with LDAP and sync 
him to LDAP

In other words, if you don't involve LDAP from beginning and you create 
1000 Keycloak users and then you later decide that you want those 1000 
users in LDAP to be available for legacy apps, you may have issues.

We want to support the 2 way sync scenario and we have JIRA for it 
already, but not sure when exactly it will be ready...

Marel
>
> We appreciate your feedback and experiences.
>
> Regards
>
> On Tue, Dec 22, 2015 at 3:02 PM Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     You can plug LDAP into Keycloak as user federation provider (See
>     Keycloak docs), but still Keycloak also needs to store users in
>     it's internal database. That's because Keycloak has various user's
>     internal metadata specific to it's logic. So usually just some
>     parts of user are stored in LDAP (you can control with LDAP
>     mappers what exactly), but all the other stuff is used in Keycloak
>     database.
>
>     Integrating Keycloak with LDAP is useful especially in case that
>     you have:
>     - Existing user base stored in LDAP
>     - Other systems or applications, which are compatible with LDAP
>     and needs to read user informations from there
>
>     If none of those is applicable for you, then it's best to skip
>     LDAP and just use Keycloak internal database. There is no need to
>     store info about user accounts in 2 places if there is no reason
>     for that.
>
>     Marek
>
>
>     On 22/12/15 14:51, Christopher Wallace wrote:
>>     We are building a new application with RBAC Security Model, we
>>     always attempt to use as much COTs functionality of our
>>     technology stack as possible. We are working with 1.7 version of
>>     KEYCLOAK for SSO (Thank you for this product by the way) We are
>>     at a decision point of where to persist our users, roles and
>>     permissions. We considered LDAP, but then with the introduction
>>     of composite roles into KEYCLOAK there was consolidation could we
>>     support users and roles directly in KEYCLOAK and permissions in
>>     our datastore. My question to the group what is the best
>>     practice? Is there value in having the additional LDAP user
>>     repository? Most places my experience is there is both LDAP or AD
>>     and SSO I wanted to keep the email fairly short, but if you have
>>     additional questions please feel free.
>>
>>     Thank You!
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20151228/4fb49f97/attachment.html 


More information about the keycloak-user mailing list