8:32 a.m.
On 17/06/16 16:07, Bill Burke wrote:
On 6/17/16 5:10 AM, Marek Posolda 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" .
>
Currently, the provider is responsible for implementing the import.
The SPI *requires* that import is implemented by hand by the
developer. The SPI *requires* a proxy which is also implemented by
hand by the developer. The provider is also responsible for
implementing synchronization. All this just to support pagination on
the admin console page.
Also, pagination sucks already in our current implementation. Consider
a query that returns 1000 users, this would require importing those
1000 users, before the pagination can even work. I don't know what we
were thinking! It was such a bad idea....
yes, however once you imported them,
they were available and in all next
queries. You were able to search on them without additional performance
penalty.
I can't see good solution for pagination TBH... Either we support it
(even if 3rd party stores doesn't have support for pagination) but then
we need import though, or we don't support it. We can see later if
people start to complain that pagination doesn't work as expected...
Bill