[keycloak-dev] Group Based Policy

[Pedro Igor Silva]

Yeah, we don't have any group claim token mapper. But if you assign a
specific role to a group and use this role to represent the group in k8s,
it should work fine. Considering that we do have a role claim token mapper
and k8s allows you to specify a claim from where groups are obtained from a
token.

A group policy could be easily achieved today if you perform the same steps
(create group + assign role to group), where users inherit the role
assigned to they groups they are member of. At the end you just need to
check the role and not really the group membership. Membership is implicit.

On Tue, Jun 6, 2017 at 7:49 PM, Bill Burke <bburke at redhat.com> wrote:

> Many companies don't have the concept of a role and everything is done
> via group membership.  Just look at Kubernates that relies on group
> membership to define permissions.
>
>
> On 6/6/17 3:18 PM, Pedro Igor Silva wrote:
> > 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
>