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.

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.

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.

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

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

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

Bill