1:37 p.m.
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
2:18 p.m.
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
5:49 p.m.
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
6:42 a.m.
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(a)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(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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2 a.m.
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
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)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(a)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>
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> 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
6:46 a.m.
Yeah, this is an old discussion .... JEE is another example about how
groups and roles are used in pretty much the same way. The really
difference is that you could actually map a set of one or more roles to a
group. But at the end is just another name with broader permissions.
On Wed, Jun 7, 2017 at 4:00 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> 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
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)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(a)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>
> 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>
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
7:45 a.m.
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
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)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(a)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>
> 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> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:02 a.m.
+1 That's a very elegant way of explaining the difference.
On 7 June 2017 at 14:45, Bill Burke <bburke(a)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
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)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(a)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>
>> 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>
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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:54 a.m.
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> 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
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)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(a)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>
>> 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>
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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:55 a.m.
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>
10:02 a.m.
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> 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> 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
> > Tel. +49 30 726112-485 <%2B49%2030%20726112-485> | Fax +49 30
> 726112-100 <%2B49%2030%20726112-100> | Sebastian.Schuster(a)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(a)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>
> >> 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>
> 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
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
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>
>
>
2:01 a.m.
If you do group-based policies, you will probably have to add group hierarchies as well,
especially if data is coming from a company LDAP.
With lots of groups, managing authorization without some kind of composition mechanism
becomes too tedious.
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
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)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(a)lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Donnerstag, 8. Juni 2017 16:55
To: Bill Burke <bburke(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Group Based Policy
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> 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
> > Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster(a)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(a)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>
> >> 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>
> 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
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:12 a.m.
I just saw hierarchical groups are already supported...just ignore me. :)
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
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)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(a)lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Donnerstag, 8. Juni 2017 16:55
To: Bill Burke <bburke(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Group Based Policy
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> 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
> > Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster(a)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(a)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>
> >> 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>
> 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
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:30 p.m.
We did ;-p
On 6/9/17 5:12 AM, Schuster Sebastian (INST/ESY1) wrote:
I just saw hierarchical groups are already supported...just ignore
me. :)
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
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)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(a)lists.jboss.org] On Behalf Of Pedro Igor Silva
> Sent: Donnerstag, 8. Juni 2017 16:55
> To: Bill Burke <bburke(a)redhat.com>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Subject: Re: [keycloak-dev] Group Based Policy
>
> 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> 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
>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>> Sebastian.Schuster(a)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(a)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>
>>>> 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>
>> 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
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:12 p.m.
I've sent a PR [1] with the GBAC policy. Basically, it supports:
* Defining a claim from where groups are obtained. We do support hierarchy
checks but the claim must hold the paths and not only their name. In case
the claim only maps to group names, we do an exact match
* Select a group using the group tree as it stands today in the group list
page
* Define if access to a selected/allowed group also extends to children
Please let me know if you want to add/change something else. There are
tests for this new policy in case you want to check how it can be used.
[1] https://github.com/keycloak/keycloak/pull/4224
Regards.
Pedro Igor
On Sat, Jun 10, 2017 at 5:30 PM, Bill Burke <bburke(a)redhat.com> wrote:
We did ;-p
On 6/9/17 5:12 AM, Schuster Sebastian (INST/ESY1) wrote:
> I just saw hierarchical groups are already supported...just ignore me. :)
>
> 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
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster(a)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(a)lists.jboss.org] On Behalf Of Pedro Igor Silva
>> Sent: Donnerstag, 8. Juni 2017 16:55
>> To: Bill Burke <bburke(a)redhat.com>
>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>> Subject: Re: [keycloak-dev] Group Based Policy
>>
>> 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> 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
>>>
>>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>>>>
>>> Sebastian.Schuster(a)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(a)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>
>>>>> 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>
>>>>>
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
4:52 p.m.
I don't think we have any group claim token mappers.
On 6/6/17 2:37 PM, Pedro Igor Silva 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
2754
days inactive
2761
days old
16 comments
4 participants
participants (4)
-
Bill Burke -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1) -
Stian Thorgersen