[keycloak-dev] restricted admin console access
Pedro Igor Silva
psilva at redhat.com
Fri May 12 11:05:26 EDT 2017
On Fri, May 12, 2017 at 10:40 AM, Bill Burke <bburke at redhat.com> wrote:
> I want business as usual for existing deployments. I don't want people
> to have to go and reconfigure existing admins when they want to add a
> restricted admin. Basically we can avoid access token bloat for
> old-school admins. The new console roles will not be added for them.
> Only restricted admins using new permission model will have the extra
> "console" roles.
>
> Let's walk through an example of creating a restricted admin that can
> only manage users that belong to a specific group.
>
> 1. Create Group "Sales"
>
> 2. Turn on fine grain permissions for "Sales" group
>
> 3. Add policy for "manage-members" for "Sales" group. Let's say if
> restricted admin has "sales-manager" role, they can manage members of
> "Sales" group
>
> 4. Lookup user "bdecoste" who is a sales manager.
>
> 5. Grant bdecoste "sales-manager" role
>
> 6. Grant bdecoste "console-access-users" role.
>
>
> Now bdecoste logs into admin console.
>
> 1. admin console queries permissions endpoint gets back a json doc:
>
> {
>
> "realm-view" : false,
>
> "clients-view" : false,
>
> "users-view" : true
>
> "groups-view" : false
>
> }
>
It seems you have created a "permission endpoint" to build this permission
json doc. But i'm wondering if can just make the admin console behave like
any other client accessing an API protected by our policy enforcers.
The idea is that the admin console would basically manage whatever the
permissions are within a RPT and send this RPT on every single request. So
we would also have the Admin REST API protected.
For instance.
1. User logs in.
2. We invoke the Entitlement API to obtain permissions for a specific set
of resources that we need to build the UI.
3. We get a RPT with the permissions. Something like that:
{
permissions: {
"resource_set_name" : "User",
"scopes": {
"view"
}
}
}
4. The admin console reads this permissions and build the Menu accordingly
where only "User" menu option is displayed.
>
> admin console only displays "Users" menu option because bdecoste only
> has the "console-access-users" role.
>
> 2. bdecoste goes to user list screen and clicks "view all users"
>
> 3. REST invocation filters out users that don't belong to "Sales" group
> based on policies set earlier
>
> 4. bdecoste clicks on a sales associate he wants to manage
>
> 5. REST call to get permissions for that user that the restricted admin
> has:
>
> {
>
> "user" : "username",
>
> "view" : true,
>
> "manage" : true
>
> }
>
> 6. Admin console displays user detail based on permissions call for that
> user
>
>
> On 5/12/17 3:39 AM, Stian Thorgersen wrote:
> > 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
> > <mailto: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
> >> <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>
> >>
> >>
> >
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list