+1 To having a way to hide bits of the console
Why not just leverage the already existing roles? We could for example
require the view-users role to be able to view users at all. Then authz
services simply determines what users are displayed.
I'd be reluctant to add more roles as it's already quite messy IMO.
Especially with the master realm. Then there's also the token size with
large number of realms. Adding yet more roles would just make that even
worse right?
On 11 May 2017 at 00:07, Bill Burke <bburke(a)redhat.com> wrote:
I'm thinking of adding additional admin roles:
"admin-console-users",
"admin-console-groups", "admin-console-clients" and a composite of
all
three: "admin-console-access". These roles exist solely for the admin
console and determine whether or not the "Users", "Clients", or
"Groups"
menu items show up. It is unfeasible to calculate this considering that
a restricted admin may have access to only one client in the admin
console or a specific set of users in a specific group.
Alternatively, I could just display the "Users', "Clients" and
"Groups"
menu item no matter what role mappings or permissions the restricted
admin has. Then when they click on that menu item, query results are
filtered based on individual permissions. I like the latter better
because its a better user experience. For example, if a restricted
admin can only manage one client and nothing else, the admin console
could bring the admin directly to that client's management page.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev