Re: [keycloak-dev] Group Based Policy

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(a)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(a)lists.jboss.org [mailto:keycloak-dev- > bounces(a)lists.jboss.org] On Behalf Of Pedro Igor Silva > Sent: Donnerstag, 8. Juni 2017 16:55 > To: Bill Burke <bburke(a)redhat.com&gt; > Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; > 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(a)redhat.com&gt; 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(a)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(a)lists.jboss.org [mailto:keycloak-dev- >>>> bounces(a)lists.jboss.org] On Behalf Of Pedro Igor Silva >>>> Sent: Dienstag, 6. Juni 2017 21:19 >>>> To: keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; >>>> 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(a)redhat.com&gt; >> 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev