[keycloak-dev] federation iteration 2

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 28 July, 2014 12:24:10 PM
> Subject: Re: [keycloak-dev] federation iteration 2
> 
> Can't drop pagination indefinitely.  Background sync will need it.  But
> for now, all of your suggestions are great.

I was only thinking about dropping pagination for admin console/endpoints.

For background sync wouldn't it be up to the federation provider to handle it? For example for LDAP if you need a cookie to manage the pagination the LDAP federation provider can just hold that internally while syncing.

> 
> On 7/28/2014 4:39 AM, Stian Thorgersen wrote:
> > Here's a thought, what about dropping pagination and instead returning a
> > maximum number of users.
> >
> > If an admin is looking for a specific user the admin is not going to want
> > to page through 10K users. So we could return say 50 users, with a message
> > saying "your search returned to many results, please refine your search".
> > Then we can improve the search feature to give better control on finding a
> > specific user. This could include:
> >
> > * Separate fields for first, last, username and email
> > * Registration date
> > * Other fields once we add customized profiles (for example DOB)
> > * By social username
> > * By role
> >
> > That should make much it easier to aggregate the results from the internal
> > db and federated stores.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Saturday, 26 July, 2014 2:20:03 AM
> >> Subject: [keycloak-dev] federation iteration 2
> >>
> >> * UserProvider interface stayed the same
> >> * Didn't add a UserFederation interface like I said I was going to,
> >> didn't have to.
> >> * UserFederationProvider interface no longer extends UserProvider and is
> >> smaller
> >> * UserFederationProvider no longer supports pagination
> >> * UserFederationProvider no longer supports getUsers().  This is a very
> >> dangerous method for large databases since we can't reliable support
> >> pagination.
> >>
> >> How does pagination work now?
> >>
> >> * getUsers() only queries local storage
> >> * search() methods will call searchByAttributes() on every provider.
> >> Then paginate based on local storage.  This may result in long query
> >> times (and database inserts) depending how many people of the same name
> >> there are.  In a database of 1 million, not sure what the distribution
> >> will be.  For example, the most popular US name is "Smith" there are 2.8
> >> million which is less than 1% of the USA.
> >>
> >> But, I'm not sure what to do.  Admins *MUST* be able to search based on
> >> names.  What would reduce the search would be to require both first and
> >> last name.
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>