[keycloak-dev] fine-grain admin permissions with Authz

[Stian Thorgersen]

The JIRA for this is https://issues.jboss.org/browse/KEYCLOAK-3444

We should provide this level of fine-grained permissions only to admins
within the realm. That will simplify both the model as well as the UI for
it. Admins in the master realm should be considered "super users" and as
such there is no need to be able to finely control what they can access.

I still want to see the master realm eventually going away and instead
levering identity brokering as a way to allow admins from one realm to
admin other realms. Not sure that's something we can introduce in a minor
update of RH-SSO though and that would probably have to wait for RH-SSO 8.
Benefits here is that permissions are managed within a single realm and
there is no restriction that both the master realm and the other realm has
to be on the same server. With some automatic "linking" of realms and a bit
of clever UI work we should be able to make it as easy to use as todays
master realm.

Within a realm it should be possible to define a subset of the users,
clients and roles that a specific admin can view and/or manage. It should
leverage the authorization services. Would be great if it's done in such a
way that it would be possible to customize it with your own policies.

On 11 March 2017 at 14:18, Bill Burke <bburke at redhat.com> wrote:

> I'm looking into how we could implement fine-grain admin permissions
> with Pedro's Authz service, i.e. fix our long standing bug that
> manage-users allows people to grant themselves admin roles.  I want to
> do an exercise of how certain things can be modeled, specific user role
> mappings.
>
> Some things we want to be able to do
>
> * admin can only assign specific roles to users
>
> * admin can only assign specific roles to users of a specific group
>
>
> The entire realm would be a Authz resource server.  There's already a
> client (resource server) for the realm "realm-management".
>
> - A Scope of "user-role-mapping" would be defined.
>
> These resources would be defined and would have the "user-role-mapping"
> scope attached to them.
>
> * "Users" resource.  This resource represents all users in the system
> * A resource is created per role
> * A resource is created per group
>
> Now, when managing roles for a user, we need to ask two questions:
>
> 1. Can the admin manage role mappings for this user?
> 2. Can the admin manage role mappings for this role?
>
> For the first question, let's map the current behavior of Keycloak onto
> the Authz service.
>
> * A scoped-base permission would be created for the "Users" resource
> with a scope of "user-role-mapping" and a role policy of role
> "manage-users".
>
> When role mapping happens, the operation would make an entitlement
> request for "Users" with a scope of "user-role-mapping".  This would
> pass by default because of the default permission defined above. Now
> what about the case where we only want an admin to be able to manage
> roles for a specific group?  In this case we define a resource for the
> Group Foo.  The Group Foo would be attached to the "user-role-mapping"
> scope.  Then the realm admin would define a scope-based permission for
> the Group Foo resource and "user-role-mapping".  For example, there
> might be a "foo-admin" role.  The scope permission could grant the
> permission if the admin has the "foo-admin" role.
>
> So, if the "Users"->"user-role-mapping" evaluation fails, the role
> mapping operation would then cycle through each Group of the user being
> managed and see if "Group Foo"->"user-role-mapping" evaluates correctly.
>
> That's only half of a solution to our problem.  We also want to control
> what roles an admin is allowed to manage.  In this case we would have a
> resource defined for each role in the system.  A scoped-based permission
> would be created for the role's resource and the "user-role-mapping"
> scope.  For example, let's say we wanted to say that only admins with
> the "admin-role-mapper" role can assign admin roles like "manage-users"
> or "manage-realm".  For the "manage-realm" role resource, we would
> define a scoped-based permission for "user-role-mapping" with a role
> policy of "admin-role-mapper".
>
> So, let's put this all together.  The role mapping operation would do
> these steps:
>
> 1. Can the admin manage role mappings for this user?
> 1.1 Evaluate that admin can access "user-role-mapping" scope for "Users"
> resource.  If success, goto 2.
> 1.2 For each group of the user being managed, evaluate that the admin
> can access "user-role-mapping" scope for that Group.  If success goto 2
> 1.3 Fail the role mapping operation
> 2. Is the admin allowed to assign the specific role?
> 2.1 Evaluate that the admin can access the "user-role-mapping" scope for
> the role's resource.
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>