Re: [keycloak-dev] initial fine-grain admin permissions

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(a)redhat.com <mailto:bburke@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>