[keycloak-dev] Group Based Policy

Fri Jun 9 03:01:28 EDT 2017

If you do group-based policies, you will probably have to add group hierarchies as well, especially if data is coming from a company LDAP.
With lots of groups, managing authorization without some kind of composition mechanism becomes too tedious.

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