[keycloak-dev] Possible Bug when listing users with fine-grained permissions

[Pedro Igor Silva]

On Wed, Jul 25, 2018 at 12:10 PM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hello,
>
> we are currently experiencing issues with the "View all users"
> functionality of the Keycloak Admin Console and the respective API call to
> /auth/admin/realms/{realm}/users when using the permissions based on the
> authorization services. In our case, we have users separated into groups
> and some users are able to view these by means of having the
> realm-management.query-users role and the group.view-members scope by means
> of a permission/policy. When such a user tries to view all the users he can
> see, he only gets a subset or even none.
>
> The reason is that in UsersResource, first a paginated subset of users is
> retrieved that is than filtered by checking visibility for each user. In
> general, this will return less users than the page and the admin UI will
> not offer to go to the next page. Even if it did, with many users where you
> can see only a small subset having to skip over lots of empty pages won’t
> be feasible.
>
> Since we really like to use this feature, we discussed several options to
> fix it:
>
> 1.     Keycloak should query for users until it reaches the number of
> requested viewable users or until it has evaluated all available users (->
> can lead to performance issues with an increasing number of users, in the
> worst case Keycloak needs to pull all users out of the database just to
> find out the current user might see none)
>
> 2.     Do the same thing but in the admin console (-> no changes in
> Keycloak but lots of request, probably even worse idea)
>
> 3.     Since groups are the resources a user needs to have view-members
> scope to see users, retrieve all groups from the database, filter out
> groups without view-members scope and then do a join by group membership
> and limit the result by paging. (-> less generalized approach, probably
> better performance as long as there are not too many groups)
>
> All of these seem to be far less than ideal.
>
> Any thoughts?
>

Yeah, all these have drawbacks and they are hard to overcome. What about
instead of hiding users, we just list all users and somehow indicate in the
list which users access is not granted. We cold avoid clicking user and
accessing his details (via UI or directly URI).


>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
> Stefan Ferber, Michael Hahn
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev