Re: [keycloak-dev] restricted admin console access

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 }

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(a)redhat.com > <mailto:bburke@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(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> >> >> > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev