10:04 a.m.
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(a)redhat.com
<mailto:bburke@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(a)redhat.com
> <mailto:bburke@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(a)bosch-si.com
> <mailto:Sebastian.Schuster@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@lists.jboss.org>
> [mailto:keycloak-dev- <mailto:keycloak-dev->
> >> bounces(a)lists.jboss.org <mailto:bounces@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
> <mailto:keycloak-dev@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(a)redhat.com <mailto:psilva@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(a)lists.jboss.org
> <mailto:keycloak-dev@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(a)lists.jboss.org
> <mailto:keycloak-dev@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(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>