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(a)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
https://lists.jboss.org/mailman/listinfo/keycloak-dev