[keycloak-dev] Group Based Policy

[Pedro Igor Silva]

Would be enough to include only the groups paths in the token ? I think
that way clients could easily check membership by looking the path for each
group. Probably using a string array claim.

On Thu, Jun 8, 2017 at 11:55 AM, Bill Burke <bburke at redhat.com> wrote:

> We need a protocol mapper for groups too for this to be able to work.
> You'll also need to change the Identity interface.
>
> On 6/8/17 10:54 AM, Pedro Igor Silva wrote:
>
> 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 <%2B49%2030%20726112-485> | Fax +49 30
>> 726112-100 <%2B49%2030%20726112-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
>>
>
>
>