[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