[keycloak-dev] User Federation Provider Cache

[Marek Posolda]

On 23/06/16 16:31, Bill Burke wrote:
> 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.
The Infinispan has method like "put(K key, V value, long lifespan, 
TimeUnit unit)" . So if the only difference is expiration time for 
different users, then it might be sufficient?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160624/5e798e9c/attachment.html