I don't think we should use the group concept for managing permissions in admin endpoints. That'll just be to confusing IMO. In either case we don't need a distinction between user and client, as we'd have roles for that.

What about domain/organization or something? Within a realm you could have one or more organizations. Users and clients belong to a single organization. Then we'd have a role namespace for the organiztion for example roles would be:

* org.keycloak/<organization name>/view-clients
* org.keycloak/<organization name>/manage-clients
* org.keycloak/<organization name>/view-users
* org.keycloak/<organization name>/manage-users

In fact you don't need groups to do that, just role namespaces and the ability to configure what "namespace" is used for a particular client or user.

On 3 November 2015 at 22:20, Bill Burke <bburke@redhat.com> wrote:
In my previous email I talked about combining Groups and Role
Namespaces.  Now I want to talk about User Groups vs. Client Groups.

User Groups would manage a set of users.  Members would automatically
inherit a set of "permissions": a set of roles.  User Groups would also
provide a set of attributes that the user inherits.

I'd like to introduce the concept of a Client Group.  Client Group would
have:

* Roles - basically a role namespace
* Permissions - set of roles service accounts members inherit
* Scope - same as our current concept of scope
* Protocol Policies - common protocol configuration.

Each Client Group would have some default roles defined.  i.e. roles
that allow a user to edit any client in the client group.

Each Client would have the same configuration options.  They would be
able to have an additional set of roles, permissions, scope, and
overridable Protocol Policies.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev