[keycloak-dev] Group Based Policy

[Bill Burke]

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 
> <mailto: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 <http://www.bosch-si.com>
>     > Tel. +49 30 726112-485 <tel:%2B49%2030%20726112-485> | Fax +49
>     30 726112-100 <tel:%2B49%2030%20726112-100> |
>     Sebastian.Schuster at bosch-si.com
>     <mailto: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>
>     [mailto:keycloak-dev- <mailto:keycloak-dev->
>     >> bounces at lists.jboss.org <mailto: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
>     <mailto: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 <mailto: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 <mailto:keycloak-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>