<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 23 June 2016 at 16:31, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.</blockquote><div><br></div><div>If we want to be able to select what providers to search the API would have to change in any case though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 6/23/16 8:53 AM, Stian Thorgersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some comments on<br>
<a href="https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI" rel="noreferrer" target="_blank">https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI</a>:<br>
<br>
* Different cache policies per provider may be difficult. Wouldn't that<br>
require having a Infinispan cache per provider? That wouldn't be very<br>
manageable.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* My vote goes to remove UserFederationProvider unless it has no impact<br>
on design of the new providers. We shouldn't sacrifice the<br>
usability/design of the new SPI for the sake of this.<br>
</blockquote>
<br></span>
With what I got so far, I've written it to be completely backward compatible and allow them to co-exist.</blockquote><div><br></div><div>Sounds good</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* We should be careful about changing behavior of LDAP provider as it's<br>
supported in product<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* JTA - should we support proper JTA transactions for consistency?<br>
<br>
</blockquote>
<br></span>
Yes, but not all federation providers will be able to take advantage of it, i.e. LDAP.</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Bill<br>
</font></span></blockquote></div><br></div></div>