[keycloak-user] To LDAP or NOT?

[Christopher Wallace]

Ok Great! Thank you Marek, If we did need to one time load to LDAP from
KEYCLOAK, I would think we could DUMP the user details from the KEYCLOAK
database and BUILD an LDIF file then do an LDAP import.

- Chris

On Mon, Dec 28, 2015 at 5:18 PM Marek Posolda <mposolda at redhat.com> wrote:

> 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> 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 listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20151229/8f5ab634/attachment.html