<div dir="ltr">I have a similar use case. The current approach assumes that the LDAP server will be available at all times. If the LDAP server goes offline, and a user is created, they won't be synced (as far as I'm aware). I'm assuming this is primarily due to the issues around transferring the password information from keycloak to an LDAP server in a useful and consistent way. I think adding either an LDAP server, or at the very least a much better API for accessing user data would be a huge win for keycloak.<div><div><br></div><div>We've hacked around this problem by implementing a custom apache ds partition that uses the keycloak libraries to talk to our database. This is made more difficult by the way these libraries are structured. For example, at least as of 1.2.0, there is no way to query the database for a list of members of a particular role. This means that I have to build this mapping myself, then cache it so that I don't have to wait many seconds for every role lookup. Also, it's not an interface that is meant for public consumption, so it may change without warning, etc. The solution we have works, but certain operations are slow, and it may cause maintenance issues. I'm going to explore using the REST API instead, though it may not expose enough information.</div></div><div><br></div><div>Another potential issue is the IDs assigned to users/roles. Keycloak currently doesn't assign IDs that would be easily mapped onto the ID space that many systems would expect (32 bit int, or similar). I think this could be worked around, but it is another challenge for any universally useful LDAP directory backed by keycloak. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 6:56 AM, Valerij Timofeev <span dir="ltr"><<a href="mailto:valerij.timofeev@gmail.com" target="_blank">valerij.timofeev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The scenario where users are created in Keycloak and then synchronized to LDAP is clear. It is good documented.<br>But what about scenario, if LDAP server setup should occur months later after Keycloak setup? <br>Would it be possible to synchronize existing Keycloak users including their password to LDAP for example on successful login?<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-10-15 12:42 GMT+02:00 Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>In that case, I would likely use
Keycloak with LDAP federation provider, which will point to some
LDAP server in your environment. KC Federation provider needs to
be declared with editMode "WRITABLE", so all users created through
Keycloak will be synced to LDAP server as well including their
password. Then the legacy product compatible just with LDAP will
authenticate users against this LDAP server.<br>
<br>
Marek<div><div><br>
<br>
On 15/10/15 11:41, Valerij Timofeev wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div>
<div dir="ltr">
<div>
<div>Hi all,<br>
<br>
we are interested to know if it is possible to authenticate
users of pure LDAP client against Keycloak?<br>
<br>
Why? We are planning to migrate legacy user storage to
Keycloak and we'd like to avoid dead end if for example some
product (e.g. SaaS) does not support user authentication
against Keycloak, but does against standard LDAP server. <br>
<br>
If it is impossible, has anybody succeeded to implement
reverted direction of user federation synchronization (all
users data from Keycloak should be copied to a fresh LDAP
server installation)?<br>
<span lang="en"><span><br>
</span></span><span lang="en"><span>Answers to these questions may be</span> <span>decisive for the Keycloak usage</span> <span>in our organization.</span></span><br>
<br>
</div>
<div>Thank you in advance<br>
<br>
</div>
<div>Valerij Timofeev<br>
</div>
<div>Software Engineer<br>
</div>
<div>Trusted Shops GmbH<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
keycloak-user mailing list
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
Andrew Zenk, EIT</div><div dir="ltr">Polar Geospatial Center<br>
University of Minnesota<br>Office: (612) 625-0872<div>Cell: (612) 414-9617</div></div></div></div></div>
</div>