[keycloak-dev] User Federation Provider Cache

Bill Burke bburke at redhat.com
Thu Jun 23 10:31:18 EDT 2016


First on pagination.  I was thinking about this a bit.  Do we really 
think that admins are going to paginate through 1000s of users?  Or will 
it be more like a couple of hundred at most?  Right now I've implemented 
something that is pretty inefficient to keep it backward compatible 
right now.  Basically I iterate all providers from the beginning until 
the page desired is identified and filled up.  Minimally it is a stop 
gap until I get everything working.

The API will need to change if we want pagination to work efficiently. 
Invokers on the API will need to keep an index as we need to know the 
last provider queried and what was the index for the last entry read. 
As a result, the REST API would have to change too.

On 6/23/16 8:53 AM, Stian Thorgersen wrote:
> Some comments on
> https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI:
>
> * Different cache policies per provider may be difficult. Wouldn't that
> require having a Infinispan cache per provider? That wouldn't be very
> manageable.

I think there is some flexibility here in the Infinispan API.  I know 
the old api at least allowed you to define zones in the cache.

> * My vote goes to remove UserFederationProvider unless it has no impact
> on design of the new providers. We shouldn't sacrifice the
> usability/design of the new SPI for the sake of this.

With what I got so far, I've written it to be completely backward 
compatible and allow them to co-exist.

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

> * JTA - should we support proper JTA transactions for consistency?
>

Yes, but not all federation providers will be able to take advantage of 
it, i.e. LDAP.

Bill


More information about the keycloak-dev mailing list