Re: [keycloak-dev] modeling map role fine grain permissions

You have to understand the Authz service. Sorry. This email was as much for me as for review. On 4/4/17 3:15 AM, Stian Thorgersen wrote: That should have come with a long email warning ;) I'm a bit lost. I read this twice without being able to wrap my head around it. I'll try to read it again later today or tomorrow. On 3 April 2017 at 16:58, Bill Burke <bburke(a)redhat.com&gt; wrote: > Here's how I am going to model role mapping with fine grain permissions > in Authz service. The goal of this is to be able to limit or expand on > who can map specific roles. While we want to have a default that any > admin that has the "manage-users" role can map a role, we also want to > be able to do things like saying that an admin can map a specific role > if they belong to a group instead. > > DEFAULT PERMISSIONS > > * "permit all" policy. Just grants it. > > * "Default Role Mapping Policy" Policy. This is an aggregate policy > that includes the "permit all" policy. > > * "map-role" scope > > * "Roles" resource. Associated scope is "map-role" > > * "Default Role Mapping Permission" - scope permission that binds > "Roles" resource and "map-role" scope. The associated policy will be > "Default Role Mapping Policy". > > > * "manage-users" scope > > * "Users" resource. Associated scope is "manage-users" > > * "manage-users" policy that checks that "manage-users" role is present > > * "Default Manage Users Policy". This is an aggregate policy that > includes the "manage-users" policy. > > * "Default Manage Users Permission". scope permission that binds > "Users" resource and "manage-users" scope. The associated policy will > be "Default Manage Users Policy". > > > The above defines the default policy for mapping all roles. In the > admin console "Roles" section, there will be a "Default Admin > Permissions" tab. Here the user will be able to modify the "Default > Role Mapping Permission". The will be able to create and add new > policies for this permission. They will not be able to create any other > permission. In the "Users" section of the admin console, there will be > a "Default Admin Permissions" tab. Here the admin will be able to > modify the "Default Manage Users Permission" > > FINE GRAIN PERMISSION > > For more fine grain permissions, there will be a resource created per > role on demand. The admin will go to the role's console page and there > will be a "Admin Permissions" tab. The admin will say they want to add > a fine grain permission for that role and this will trigger these actions: > > * A resource will be created specifically for that role with an > associated scope of "map-role" > > * A scope permission will be created for that role resource and the > "map-role" scope. The "Default Role Mapping Policy" will be added > automatically to this permission. > > THere will also be a "Admin Permissions" tab for each Group. The admin > will say they want to add a fine grain permission for that group and > this will trigger these actions: > > * A resource will be created specifically for that group with an > associated scope of "manage-users" > > * A scope permission will be created for that group resource and the > "manage-users" scope. The "Default Manage User Policy" will be added > automatically to this permission. > > EVALUATION > > When evaluating whether or not a role is allowed to be mapped by a > particular admin, this will be the algorithm: > > 1. If there is a resource for that specific role, evaluate that the > admin can use the "map-role" scope with that role's resource > > 2. If there is not a resource for that specific role, then evaluate that > teh admin can use the "map-role" scope with the "Roles" resource. > > 3. Evaluate if the admin can perform the "manage-users" scope on the > "Users" resource. > > 4. If Step #3 fails, then for each group see if the admin has the > "manage-users" scope for that group. > > DEFAULT PERMISSIONS FOR ADMIN ROLES > > By default, each admin role in the system "manage-users", > "manage-realm", etc... will have a resource ad scope permission created > for it as articulated above. The scope permission will be UNANIMOUS and > will also associate a role policy of that role in addition to the > "Default Role Mapping Policy". This additional role policy is basically > saying "Admins with 'manage-users' role and the admin must have this > role mapping as well". So, somebody with 'manage-users' role can't map > 'manage-realm' unless they have that role themselves. > > MORE FINE GRAIN PERMISSIONS > > We also want to solve the case of allowing an admin to be able to map > specific roles for members of a specific group. To do this we'll add > another policy type called "Has Permission". Here you'll be able to > link a permission to a policy. So, to solve the use case for specific > roles for members of a specific group, we can edit the "map-role" > permission for a specific role and add a "Has Permission" that links to > the permission that the admin has "manage-users" scope for a specific > group. Hope I'm making sense on this one. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >