[keycloak-dev] User Federation Provider Cache
Bill Burke
bburke at redhat.com
Fri Jun 24 12:49:16 EDT 2016
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
More information about the keycloak-dev
mailing list