<div dir="ltr">There could be benefits to sync/import, but we don't see these even in the current implementation:<div><br></div><div>* Migration - users may want to migrate away from LDAP gradually. We should support some mechanism of permanently migrating all users from a provider to the internal Keycloak DB (or even another provider).</div><div>* Scaling - if users in an LDAP server are more or less read-only then you would only have to load users from the Keycloak DB. This may be useful if the LDAP server is overloaded and you want to scale. However, that could possibly also be solved by more aggressive caching.</div><div><br></div><div>Can you elaborate a bit on why you think the current sync/import is really really bad?</div><div><br></div><div>With the new model there's a few things I'm a bit unsure about:</div><div><br></div><div>* Will there always be a representation of a user in Keycloak DB? For the UUID as well as other items that can't be stored in the provider. Or will we have the option of not having anything in the KC DB about a user, only in-mem?</div><div>* By supporting the old UserFederationProvider will those have exactly the same behavior? For example with regards to sync/import?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 June 2016 at 18:49, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 6/24/16 12:34 AM, Marek Posolda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* We should be careful about changing behavior of LDAP provider as it's<br>
supported in product<br>
</blockquote>
<br>
Honestly, we made a very bad decision to not refactor the federation<br>
SPI and to force users to import. It is going to be a really big<br>
headache to migrate existing LDAP users to the new LDAP provider.<br>
IMO, it is ultra important to stop importing everything.<br>
</blockquote>
Maybe I am missing something, but not sure why is it a headache? Is it<br>
because of the UUID of user is going to change to new format like<br>
f:<PROVIDER-UUID> , so users may not be referenced from the applications<br>
with correct UUID? This looks to be a migration issue for all existing<br>
federation providers, not just LDAP specific?<br>
<br>
</blockquote>
<br></span>
We don't support federation providers in product except for LDAP and Kerberos. There are a few migration headaches:<br>
<br>
* New model won't support on-demand loading or proxying. It will work just as the current JPA and Mongo UserProviders work.<br>
* With importing, you don't know where the import begins and ends and it will be very hard to unwind it to use a non-importing LDAP impl. Honestly, I just don't want to support import and sync. I think it is really really bad.<br>
<br>
As for existing deployments, it looks like I can keep the UserFederationProvider SPI and have it co-exist with the new one. We can do that and @Deprecate the UserFederation SPI. We might want to consider keeping support for the old LDAP provider in product too. For example, if one exists, show the admin console screens for it, if one doesn't don't show the screens for it.<span class="HOEnZb"><font color="#888888"><br>
<br>
Bill<br>
</font></span></blockquote></div><br></div>