[keycloak-dev] Group Based Policy

[Bill Burke]

We did ;-p


On 6/9/17 5:12 AM, Schuster Sebastian (INST/ESY1) wrote:
> I just saw hierarchical groups are already supported...just ignore me. :)
>
> Mit freundlichen Grüßen / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>> bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
>> Sent: Donnerstag, 8. Juni 2017 16:55
>> To: Bill Burke <bburke at redhat.com>
>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Group Based Policy
>>
>> Yeah, that is what I also think. In any case, I'm going to implement a group policy
>> as users may not want to assign roles to their groups every time they want a
>> group-based access control mechanism associated with their permissions. You
>> can do it that way, but in some cases (like the one you
>> mentioned) it may be boring specially when groups come from LDAP without roles
>> associated with them.
>>
>> On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Groups and roles can from a technological perspective be used for the
>>> same purpose.  But in my mind, Groups are for organizing sets of
>>> users.   Composite Roles are for managing a set of permissions often
>>> defined by applications.
>>>
>>>
>>> On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
>>>> I agree 100% with your arguments against supporting group-based
>>> policies. :) I guess people doing authorization based on groups are
>>> essentially using roles, they are just calling them groups. Keycloak
>>> can perfectly cover that case by using roles. The only potential
>>> difference I see is when there is something like composite roles or composite
>> groups.
>>> With a composite role, you get all the subroles. With a composite
>>> group, you are in all the parent groups. However, offering this
>>> opposite direction (and adding composite groups) comes at the price of
>>> making it even harder for people to decide what they should (and do it
>>> correctly) so I don’t think it's really worth it.
>>>> I do like the current RBAC way as it is a very clear concept. You
>>>> can
>>> still switch to ABAC if RBAC does not cover your case...
>>>> Mit freundlichen Grüßen / Best regards
>>>>
>>>>    Sebastian Schuster
>>>>
>>>> Engineering and Support (INST/ESY1)
>>>> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785
>>>> Berlin
>>> | GERMANY | www.bosch-si.com
>>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>>> Sebastian.Schuster at bosch-si.com
>>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
>>>> 148411 B
>>>> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>>> bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
>>>>> Sent: Dienstag, 6. Juni 2017 21:19
>>>>> To: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>>> Subject: Re: [keycloak-dev] Group Based Policy
>>>>>
>>>>> Forgot to add something to the discussion.
>>>>>
>>>>> I'm not 100% sure if we should have a group policy though. Reason
>>>>> being
>>> that
>>>>> groups are usually administrative things to group a set of one or
>>>>> more
>>> users and
>>>>> usually they are not really suitable for authorization. For
>>>>> instance,
>>> with current
>>>>> design you could enforce access based on groups as long as your
>>>>> groups
>>> have a
>>>>> specific role which you can use in a role based policy. In this
>>>>> sense,
>>> roles are
>>>>> definitely more suitable for authorization than groups.
>>>>>
>>>>>
>>>>> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva
>>>>> <psilva at redhat.com>
>>> wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I'm adding a Group Based Policy to our set of supported policies.
>>>>>> Basically, this policy allows you to define the group(s) you want
>>>>>> to give access to some resource or scope.
>>>>>>
>>>>>> Would like to share my initial scope with you and see if you guys
>>>>>> have anything else to add:
>>>>>>
>>>>>> * Users can select one or more groups
>>>>>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
>>>>>> /Group A, /Group A/Group B)
>>>>>> * Users can decide whether or not access is granted if the
>>>>>> identity is a member of all or any of the selected groups
>>>>>> * Users can decide whether or not access extends to sub-groups of
>>>>>> a parent group
>>>>>>
>>>>>> Please, let me know your thoughts.
>>>>>>
>>>>>> Regards.
>>>>>> Pedro Igor
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> 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
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> 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