I don't want to add more roles either, but I currently don't see a way
to model your suggestion. This is why I'm posting to dev, because I
need ideas. Everything is currently modeled as granting additional
access, not restricting existing access. "view-users" grants viewing
access to all users and we can't break backward compatibility. I just
don't know how restricting viewing to a specific group of users could be
modeled.
The current way I have it modeled is:
1. See if admin can view all users . There is a resource that
represents all users. I ask policy engine if admin has "view" scope for
"Users" resource (i.e. (has "view-users" role). If this passes, I let
them view the user
2. If #1 fails, then loop through each group the user belongs to. If
admin has "view_members" scope for the group, i let the admin view the user
If we do as you suggest, then you'd have to do the opposite of above
1. See if admin can view all users. (has "view-users" role). This
doesn't grant access yet, proceed to step 2.
2. Loop through each group the user belongs to and see if the admin is
restricted from viewing members of this group.
Do you see the problem here? How do you model the restriction AND, at
the same time, make sure you're backward compatible with "view-users"
behavior?
On 5/11/17 1:07 AM, Stian Thorgersen wrote:
+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
<mailto:bburke@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 <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>