<div dir="ltr"><div><div><div>Thank you, Andrew.<br><br>Your approach is an interesting option I did not consider yet. <br></div>Would be this URL  a good starting point to estimate complexity of your approach? <br><a href="https://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+How+to+write+a+simple+custom+partition+for+ApacheDS">https://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+How+to+write+a+simple+custom+partition+for+ApacheDS</a> <br>We don&#39;t need LDAP just at the moment. But I have to 
demonstrate to decision makers in our organization that Keycloak is not a
 dead end user management solution.<br><br></div>Have you considered normal LDAP user federation option in combination with setting up ApacheDS to use PBKDF2 algorithm for compatibility during migration?<br><a href="https://issues.apache.org/jira/browse/DIRSERVER-1898">https://issues.apache.org/jira/browse/DIRSERVER-1898</a><br><br><br></div><br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-15 15:22 GMT+02:00 Andrew Zenk <span dir="ltr">&lt;<a href="mailto:azenk@umn.edu" target="_blank">azenk@umn.edu</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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&#39;t be synced (as far as I&#39;m aware).  I&#39;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&#39;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&#39;t have to wait many seconds for every role lookup.  Also, it&#39;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&#39;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&#39;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"><div><div class="h5"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 6:56 AM, Valerij Timofeev <span dir="ltr">&lt;<a href="mailto:valerij.timofeev@gmail.com" target="_blank">valerij.timofeev@gmail.com</a>&gt;</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><div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-15 12:42 GMT+02:00 Marek Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</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 &quot;WRITABLE&quot;, 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&#39;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" target="_blank">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></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><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>
</font></span></div>
</blockquote></div><br></div>