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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user

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(a)redhat.com&gt; 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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > >