[keycloak-dev] modeling map role fine grain permissions

[Stian Thorgersen]

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