Re: [keycloak-dev] user groups vs. client groups
On 3 November 2015 at 22:20, Bill Burke <bburke(a)redhat.com> wrote:
+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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
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.
Attachments:
- attachment.html (text/html — 3.4 KB)