10:10 a.m.
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?
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@bosch-si.com<mailto:Sebastian.Schuster@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
7:06 a.m.
On Wed, Jul 25, 2018 at 12:10 PM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)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@bosch-si.com<mailto:Sebastian.Schuster@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:56 a.m.
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.
Do you think that the third approach, filtering groups and joining contained users, would
be worth investigating?
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@bosch-si.com<mailto:Sebastian.Schuster@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(a)redhat.com>
Sent: Donnerstag, 26. Juli 2018 14:06
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
Cc: keycloak-dev <keycloak-dev(a)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@bosch-si.com<mailto:Sebastian.Schuster@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><http://www.bosch-si.co...
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:57 p.m.
On Thu, Jul 26, 2018 at 11:56 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)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%0AG...
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)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(a)redhat.com>
*Sent:* Donnerstag, 26. Juli 2018 14:06
*To:* Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
*Cc:* keycloak-dev <keycloak-dev(a)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(a)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&...
| www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:11 a.m.
Thanks Pedro, issue created: https://issues.jboss.org/browse/KEYCLOAK-7950
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@bosch-si.com<mailto:Sebastian.Schuster@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(a)redhat.com>
Sent: Donnerstag, 26. Juli 2018 19:57
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Possible Bug when listing users with fine-grained
permissions
On Thu, Jul 26, 2018 at 11:56 AM, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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%0AG...
GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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@redhat.com<mailto:psilva@redhat.com>>
Sent: Donnerstag, 26. Juli 2018 14:06
To: Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
Cc: keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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@bosch-si.com<mailto:Sebastian.Schuster@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+%...
| www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.co...
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2114
days inactive
2116
days old
4 comments
2 participants
participants (2)
-
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1)