[keycloak-dev] User Federation Provider Cache

[Stian Thorgersen]

There could be benefits to sync/import, but we don't see these even in the
current implementation:

* 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).
* 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.

Can you elaborate a bit on why you think the current sync/import is really
really bad?

With the new model there's a few things I'm a bit unsure about:

* 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?
* By supporting the old UserFederationProvider will those have exactly the
same behavior? For example with regards to sync/import?

On 24 June 2016 at 18:49, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 6/24/16 12:34 AM, Marek Posolda wrote:
>
>> * We should be careful about changing behavior of LDAP provider as it's
>>>> supported in product
>>>>
>>>
>>> Honestly, we made a very bad decision to not refactor the federation
>>> SPI and to force users to import.  It is going to be a really big
>>> headache to migrate existing LDAP users to the new LDAP provider.
>>> IMO, it is ultra important to stop importing everything.
>>>
>> Maybe I am missing something, but not sure why is it a headache? Is it
>> because of the UUID of user is going to change to new format like
>> f:<PROVIDER-UUID> , so users may not be referenced from the applications
>> with correct UUID? This looks to be a migration issue for all existing
>> federation providers, not just LDAP specific?
>>
>>
> We don't support federation providers in product except for LDAP and
> Kerberos.  There are a few migration headaches:
>
> * New model won't support on-demand loading or proxying.  It will work
> just as the current JPA and Mongo UserProviders work.
> * 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.
>
> 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.
>
> Bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160627/4fca2f84/attachment.html