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

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