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@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@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
_______________________________________________ keycloak-dev mailing list keycloak-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev