[keycloak-dev] initial fine-grain admin permissions

[Stian Thorgersen]

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