[keycloak-dev] modeling map role fine grain permissions
sthorger at redhat.com
Tue Apr 4 03:15:48 EDT 2017
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 at redhat.com> 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.
> 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 at lists.jboss.org
More information about the keycloak-dev