[keycloak-dev] user groups vs. client groups

[Marek Posolda]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151105/8ef7297c/attachment.html