[keycloak-dev] modeling map role fine grain permissions

[Stian Thorgersen]

Can you gives us the high level, non-authz services, specific version? ;)

On 4 April 2017 at 14:59, Bill Burke <bburke at redhat.com> wrote:

> 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 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
>>
>
>
>