[keycloak-dev] User Federation Provider Cache

[Stian Thorgersen]

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.
* 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.
* We should be careful about changing behavior of LDAP provider as it's
supported in product
* JTA - should we support proper JTA transactions for consistency?


On 23 June 2016 at 14:46, Stian Thorgersen <sthorger at redhat.com> wrote:

> Admins will still want the ability to manage users through the admin
> console.  That's important, especially since not all capabilities like
> required actions might be available from for example an LDAP management
> util. That being said I don't think there's a need to have a full import
> for it. Rather the admin console could be slightly changed/tweaked.
>
> I propose we add an option to select what providers to search. If one or
> more of the selected providers doesn't support pagination we should remove
> the view all option as well as the pagination.
>
> On 17 June 2016 at 11:10, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 16/06/16 16:38, Bill Burke wrote:
>> >>>> Sync users
>> >>>> --------------
>> >>>> We should still keep the option to sync users into Keycloak DB as we
>> >>>> have now. Note some persistent storages like LDAP are limited with
>> >>>> pagination. So the easiest possibility for some admins is just to
>> sync
>> >>>> users, so they can easily search them in admin console.
>> >>>>
>> >>> Doing a full import just to support pagination is overkill. I'm
>> >>> guessing that a lot of deployments will not manage users through the
>> >>> Keycload admin console.  We can offer a manual a Sync SPI that
>> >>> providers can implement.
>> >> Maybe it's overkill for 90% of deployments, but remaining 10% want to
>> >> see all LDAP users in admin console immediatelly and hence want to sync
>> >> them? IMO it's always good to have SPI flexible so it can easily
>> support
>> >> all the possible requirements. However I understand that it's not
>> always
>> >> possible...
>> >>
>> >
>> > This is only an issue for large query result sets where you want to do
>> > pagination.  IIRC, we couldn't figure out a way to do this in a
>> > scalable manner without imports.
>> yeah, I also can't see how to do pagination without imports, assuming
>> the 3rd party store (ie. LDAP) doesn't have pagination support.
>>
>> So then again, the question is if SPI should still have the option to
>> support imports? Or maybe don't have it OOTB, but if customers start
>> asking for pagination, we have the option to say them "ok, we will try
>> to add it" instead of "no, you can't do that and there is no way to
>> support it with current SPI" .
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160623/d972c145/attachment.html