[keycloak-dev] Group Based Policy

Stian Thorgersen sthorger at redhat.com
Thu Jun 8 02:02:27 EDT 2017


+1 That's a very elegant way of explaining the difference.

On 7 June 2017 at 14:45, 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
>


More information about the keycloak-dev mailing list