On Sat, Mar 11, 2017 at 10:18 AM, Bill Burke <bburke(a)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
You could also create different resources for each user.
It is worthy mentioning about our permissioning model is that we support
typed resources. For instance, you can define a typed resource that
represents all users (your "Users" resources) and assign some general
policies that must be applied to all users. When you create an user you can
also create a resource representing that particular user with the same type
as the typed resource (we call a resource instance). That means that all
policies associated with the typed resource are also enforced for any other
resource with the same type.
In addition, you can also define specific policies for a resource instance
(e.g.: a resource representing a specific user) to enforce additional
policies for an user.
The same applies for roles, groups or any other resource you are protecting.
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.
Are you already implementing things ? Do you want me to look at these
changes or work together with you on them ?
(As you may have noticed, there is an API that we use internally to
actually evaluate policies given a set of permissions.)
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev