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.

Permission != role
 

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

* Roles - basically a role namespace

-1 Having roles tied to a client or client group is exactly what we should go away from. IMO role namespaces should be a completely separate thing.
 
* Permissions - set of roles service accounts members inherit

-1 It shouldn't be called permissions, it would be role mappings. In either case a service account is backed by a regular user, which can be part of a user group and would get role mappings from there.
 
* Scope - same as our current concept of scope 
* Protocol Policies - common protocol configuration.

+1 To scope and protocol policies
 

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

I don't understand this
 

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. 

Same comment as above - why would a client have roles/permissions? I assume we where moving away from that with role namespaces
 

--
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