[keycloak-dev] user groups vs. client groups

[Stian Thorgersen]

Ignore my previous response - I completely miss-read what was being
proposed ;)

On 5 November 2015 at 12:12, Marek Posolda <mposolda at redhat.com> wrote:

> 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> 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>
>> 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
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151105/119cea20/attachment-0001.html