[keycloak-dev] User Federation Provider Cache

[Stian Thorgersen]

On 23 June 2016 at 16:31, Bill Burke <bburke at redhat.com> 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.
>

I doubt anyone would and instead search for users if there are many. With
that in mind a solution that fetches a maximum number of users would work
fine.

Can we at least show a count? It would be helpful to be able to show the
total number of users and maybe even users per provider. As well as showing
total number of users returned by a search.


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


If we want to be able to select what providers to search the API would have
to change in any case though.


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


If that's possible then allowing configuring it per-realm or even
per-provider could be beneficial. I'd say it's a priority 2 though.


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


Sounds good


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


Forcing users to import true, but having the option to import is good. One
thing quite a few people have asked me is if we support migrating users
completely. Unless you have workstations authenticating to LDAP there's no
need to keep an LDAP server around once all your web apps are migrated to
Keycloak. Could we have an option to decommission a provider that would
provide the option to either import all users or to remove all
corresponding user data (required actions, etc..) in Keycloak?


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


Sure, I don't even think it should be enabled by default. The option would
be nice to have though. Same goes to other providers. Although for JPA the
better approach is to use a single db and transaction rather than XA
transactions. We've just had the ability to add custom entities merged in
2.0.0.CR1 that would allow someone to create user provider that shares the
same entity manager and connect/transaction with the realm, user, etc
stores.


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