<div dir="ltr">Some comments on <a href="https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI">https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI</a>:<div><br></div><div>* Different cache policies per provider may be difficult. Wouldn't that require having a Infinispan cache per provider? That wouldn't be very manageable.</div><div>* 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.</div><div>* We should be careful about changing behavior of LDAP provider as it's supported in product</div><div>* JTA - should we support proper JTA transactions for consistency?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 June 2016 at 14:46, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><div class="h5"><div><div class="gmail_extra"><br><div class="gmail_quote">On 17 June 2016 at 11:10, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 16/06/16 16:38, Bill Burke wrote:<br>
</span><span>>>>> Sync users<br>
>>>> --------------<br>
>>>> We should still keep the option to sync users into Keycloak DB as we<br>
>>>> have now. Note some persistent storages like LDAP are limited with<br>
>>>> pagination. So the easiest possibility for some admins is just to sync<br>
>>>> users, so they can easily search them in admin console.<br>
>>>><br>
>>> Doing a full import just to support pagination is overkill. I'm<br>
>>> guessing that a lot of deployments will not manage users through the<br>
>>> Keycload admin console. We can offer a manual a Sync SPI that<br>
>>> providers can implement.<br>
>> Maybe it's overkill for 90% of deployments, but remaining 10% want to<br>
>> see all LDAP users in admin console immediatelly and hence want to sync<br>
>> them? IMO it's always good to have SPI flexible so it can easily support<br>
>> all the possible requirements. However I understand that it's not always<br>
>> possible...<br>
>><br>
><br>
> This is only an issue for large query result sets where you want to do<br>
> pagination. IIRC, we couldn't figure out a way to do this in a<br>
> scalable manner without imports.<br>
</span>yeah, I also can't see how to do pagination without imports, assuming<br>
the 3rd party store (ie. LDAP) doesn't have pagination support.<br>
<br>
So then again, the question is if SPI should still have the option to<br>
support imports? Or maybe don't have it OOTB, but if customers start<br>
asking for pagination, we have the option to say them "ok, we will try<br>
to add it" instead of "no, you can't do that and there is no way to<br>
support it with current SPI" .<br>
<span><font color="#888888"><br>
Marek<br>
</font></span><div><div>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>