[keycloak-dev] restricted admin console access

[Bill Burke]

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 at redhat.com 
> <mailto:bburke at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>