[keycloak-dev] restricted admin console access

[Stian Thorgersen]

Just to be clear I'm a bit too much of a noob on the authz services to be
very helpful, so I'm just trying to help as much as I can.

What about there's two modes for a realm. Old backwards compatible mode
with no authz services involved. This will just work exactly how it does
today. Then there's the new mode which uses authz services. The new mode
doesn't have to be compatible, but I guess we'd need to be able to easily
switch a realm from the old to the new.

That way you could switch the behaviour to what you're saying below.
"view-users" just gives permission to invoke the endpoints and show the
console bits, then authz services kicks in to control what users a user can
see?

On 11 May 2017 at 23:02, Bill Burke <bburke at redhat.com> wrote:

> 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> 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
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>