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

[Pedro Igor Silva]

On Mon, Mar 13, 2017 at 7:03 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

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

I think we can achieve that already. Although, depending on how many users
a realm may have we may need to revisit UI controls in order to improve
usability.

I'm going to try to prepare something to our next meeting at this regard.


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