Re: [keycloak-dev] user groups vs. client groups

I like also the possibility to have "common" set of protocol mappers shared between more clients. Also in my client application, I may want to share roles defined in 2 different namespaces. So IMO it will be good if client can be added to more different client groups/organizations and inherit common roles, protocol mappers and scopes from all of them. Marek On 05/11/15 11:34, Stian Thorgersen wrote: However, maybe we should not try to introduce more fine-grained permissions in admin endpoints at the moment. In the future we should be able to leverage Pedro's work and do it properly. On 5 November 2015 at 11:33, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > 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(a)redhat.com&gt; > bburke(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev