[keycloak-dev] Group Based Policy

Tue Jun 13 18:12:56 EDT 2017

I've sent a PR [1] with the GBAC policy. Basically, it supports:

* Defining a claim from where groups are obtained. We do support hierarchy
checks but the claim must hold the paths and not only their name. In case
the claim only maps to group names, we do an exact match
* Select a group using the group tree as it stands today in the group list
page
* Define if access to a selected/allowed group also extends to children

Please let me know if you want to add/change something else. There are
tests for this new policy in case you want to check how it can be used.

[1] https://github.com/keycloak/keycloak/pull/4224

Regards.
Pedro Igor

On Sat, Jun 10, 2017 at 5:30 PM, Bill Burke <bburke at redhat.com> wrote:

> 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
>>>
>>
>