[keycloak-dev] Group Based Policy
Bill Burke
bburke at redhat.com
Thu Jun 8 11:04:03 EDT 2017
Yes that works.
On 6/8/17 11:02 AM, Pedro Igor Silva wrote:
> 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
> <mailto: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
>> <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>
>>
>>
>
>
More information about the keycloak-dev
mailing list