[keycloak-dev] initial fine-grain admin permissions

Bill Burke bburke at redhat.com
Thu Mar 23 10:02:27 EDT 2017

I'm just trying to define the initial operations we want to cover and 
how fine grain we might want to go.   When I wrote "Admin can" below, I 
do not discuss how the admin is defined.  I'll get into what default 
policies will be later on as I learn the limitations of the Authz 
service.  I want to implement as you describe, not defining permissions 
PER ADMIN, but based on group membership and role mappings of the admin 

On 3/23/17 1:54 AM, Stian Thorgersen wrote:
> That seems to cover the use-cases I had in mind. I'd also like to 
> highlight what Marek pointed out around protocol mappers. That was 
> found as one of the issues with dynamic client registration that we 
> had to tackle. Basically it could have been used for priviledge 
> escalation through the client registration services. We solved that by 
> introducing the client registration policies. Maybe we need different 
> policies applied to different admins.
> How would this be encoded? Rather than having lists of admin can 
> access this, admin can access that. Would it not be better to have 
> some role or group where a member of that role/group can access a set 
> of users, a set of roles, a set of clients, etc..?
> On 21 March 2017 at 22:10, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>     Here's what we want to be able to manage for fine-grain admin
>     permissions for the 1st iteration.  If you think we need more, let me
>     know, but I want to keep this list as small as possible.
>     User management
>       * Admin can only apply certain roles to a user
>       * Admin can view users of a specific group
>       * Admin can manage users of a specific group (creds, role
>     mappings, etc)
>     Group Management
>       * Admin can only manage a specific group
>       * Admin can only apply certain roles to a group
>       * Admin can only manage attributes of a specific group
>       * Admin can control group membership (add/remove members)
>     Client management:
>       * Admin can only manage a specific client.
>       * Admin can manage only configuration for a specific client and not
>         scope mappings or mappers.  We have this distinction so that
>     rogues
>         can't expand the scope of the client beyond what it is allowed to.
>       * Service accounts can manage the configuration of the client by
>     default?
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>

More information about the keycloak-dev mailing list