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

[Pedro Igor Silva]

On Thu, Jul 26, 2018 at 11:56 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi Pedro,
>
>
>
> That would be kind of consistent with the behavior of the role
> “query_groups”, allowing you to also see all group names, ids, and
> subgroups. However, on the users endpoint you get a lot more data, partly
> personal.
>
> Unless the API is changed here (unlikely as it would be incompatible), I
> would prefer the current behavior of not seeing users at all if you miss
> the permission.
>

Yeah, I was thinking about something similar to "query_groups". Agree that
for users this is should work differently.


>
>
> Do you think that the third approach, filtering groups and joining
> contained users, would be worth investigating?
>

Yes, #3 seems to me the best among those options. Could you create a JIRA
to track this ? One more thing to check when reviewing this functionality
...


>
>
> 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 |
> <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C++%0D%0AGERMANY&entry=gmail&source=g>
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> 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
>
>
>
> *From:* Pedro Igor Silva <psilva at redhat.com>
> *Sent:* Donnerstag, 26. Juli 2018 14:06
> *To:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Subject:* Re: [keycloak-dev] Possible Bug when listing users with
> fine-grained permissions
>
>
>
>
>
>
>
> 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
> <https://maps.google.com/?q=Ullsteinstr.+128+%7C+12109+Berlin+%7C+GERMANY&entry=gmail&source=g>
> | 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
>
>
>