[keycloak-dev] user groups vs. client groups

[Stian Thorgersen]

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> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151105/612f4fca/attachment.html