You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by James Flemer <ja...@ndpgroup.com> on 2013/06/04 07:21:30 UTC
Syncope User & Role entitlements (role management delegation)
Hi,
I have a use case for role management delegation. The desired use case is:
A given user, "the Manager", is permitted to add and remove other users
from a set of one or more "managed roles", but is not permitted to modify
role membership for other roles.
NOTE: All following comments apply to Syncope 1.1.0 / 1.1.x.
The current USER_* and ROLE_* entitlements are somewhat confusing (perhaps
incomplete), and unfortunately do not support the use case above.
The USER_LIST entitlement actually behaves like:
"allow listing all users who's set of roles is a subset of my role
entitlements"
In other words, a user (with USER_LIST) cannot see other users if they have
a role that the user does not have an entitlement to. I would have
expected that USER_LIST would allow listing of all users, or I would expect
another entitlement like USER_LIST_ALL to cover that case. The "list
users" capability is needed for the use case above, the manager needs the
ability to see all users.
The USER_UPDATE and USER_READ entitlements seems to be unconditional, they
are NOT limited according to Role as USER_LIST is. This is inconsistent.
Additionally, USER_LIST and USER_READ are somewhat overlapping. Listing
user includes all the detail in USER_READ. However, USER_LIST doesn't
allow reading user by id or username (even though list provides this data).
There is no ROLE_LIST entitlement, and it appears that roles can be listed
(in full detail) without any authentication or authorization. Although
this doesn't break the use case above, it doesn't seem that roles should be
listable without authn/authz. Again this is inconsistent with ROLE_READ
which is required to read a role by id, even though list provides the same
detail.
Some suggestions, or a starting point for discussion:
1. Change USER_LIST to permit listing of *ALL* users (regardless of
roles).
2. Create ROLE_LIST, and make it required to list roles.
3. Allow USER_LIST in all places where USER_READ+ROLE_x is required
(i.e. USER_LIST is a superset of USER_READ).
4. Require USER_UPDATE+ROLE_x entitlement to add/delete role "x" from a
user.
I'm not sure the above mods are the correct approach. These suggestions
still leave a bit of ambiguity, and likely conflict with the needs for
other use cases. However, I think the use case where "the Manager" who is
permitted to control the membership of a sub-set of roles is quite common.
With the above, the following example should work (names used instead of
numbers for clarity):
Role "foo-mgr" has entitlement "USER_LIST, USER_READ, USER_UPDATE,
ROLE_LIST, ROLE_READ, ROLE_foo1, ROLE_foo2".
User "themgr" has role "foo-mgr"
User "joe" has role "bar1".
Then, "themgr" can log in, find "joe" and add (or remove) "joe" from the
"foo1" and/or "foo2" roles.
However, "themgr" cannot remove "joe" from "bar1" (because "themgr" does
not have the "ROLE_bar1" entitlement).
Regards,
James Flemer
Re: Syncope User & Role entitlements (role management delegation)
Posted by James Flemer <ja...@ndpgroup.com>.
Hi Francesco,
Thanks for the detailed response, and no worries on the delay, I
understand! I had missed the addition of the role owner feature in 1.1.0,
but it looks like that might help address our needs. Considering the
proposed changes in SYNCOPE-119 for 1.2.0, I will probably hold off on
trying to do any modifications on the 1.1.x entitlements. I'll let you
know how the "role owner" works out.
Thanks again,
-James
On Fri, Jun 21, 2013 at 1:12 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
> On 20/06/2013 22:55, James Flemer wrote:
>
>> Hello,
>>
>> Any comments on these suggestions/discussion regarding roles and
>> entitlements? I'd like some feedback from the core developers if this
>> approach seems reasonable, and whether patches with these or similar
>> changes might or might not be accepted into the project. Thanks!
>>
>
> Hi James,
> sorry for the delay: busy period...
>
> See my comments inline below.
>
> Regards.
>
>
> On Mon, Jun 3, 2013 at 11:21 PM, James Flemer <ja...@ndpgroup.com>
>> **wrote:
>>
>> Hi,
>>>
>>> I have a use case for role management delegation. The desired use case
>>> is:
>>> A given user, "the Manager", is permitted to add and remove other
>>> users
>>> from a set of one or more "managed roles", but is not permitted to modify
>>> role membership for other roles.
>>>
>>
> Premise: the whole authorization is going to be refactored in Syncope
> 1.2.0 by introducing realms (see SYNCOPE-119 and related).
>
> I understand that you have already read [1].
> Have you also been playing with role ownership. introduced by [2] since
> Syncope 1.1.0? I have just updated [1] with some basic information about
> this.
>
> Basically, an user or a role can be defined "owner" of another role (this
> is similar to Active Directory's group owner).
> Users owning role A (or members of a role owning role A) are automatically
> granted entitlements ROLE_CREATE / ROLE_READ / ROLE_UPDATE / ROLE_DELETE +
> ROLE_A + ROLE_X where X is a descendant of A with inheritOwner=true.
> This is done at [3], lines 81:92.
>
> Could you please try to re-think your use case with this information?
>
>
> NOTE: All following comments apply to Syncope 1.1.0 / 1.1.x.
>>>
>>> The current USER_* and ROLE_* entitlements are somewhat confusing
>>> (perhaps
>>> incomplete), and unfortunately do not support the use case above.
>>>
>>> The USER_LIST entitlement actually behaves like:
>>> "allow listing all users who's set of roles is a subset of my role
>>> entitlements"
>>> In other words, a user (with USER_LIST) cannot see other users if they
>>> have a role that the user does not have an entitlement to. I would have
>>> expected that USER_LIST would allow listing of all users, or I would
>>> expect
>>> another entitlement like USER_LIST_ALL to cover that case. The "list
>>> users" capability is needed for the use case above, the manager needs the
>>> ability to see all users.
>>>
>>
> Introducing a USER_LIST_ALL can indeed be an option.
>
>
> The USER_UPDATE and USER_READ entitlements seems to be unconditional, they
>>> are NOT limited according to Role as USER_LIST is. This is inconsistent.
>>>
>>
> This is not true: UserController#update(UserMod) and
> UserController#read(username) are respectively bound to USER_UPDATE and
> USER_READ by Spring Security annotations *and* checked against role
> operational entitlements.
> More generally, any REST service that needs to access user details from
> JPA store is checked against this.
>
>
> Additionally, USER_LIST and USER_READ are somewhat overlapping. Listing
>>> user includes all the detail in USER_READ. However, USER_LIST doesn't
>>> allow reading user by id or username (even though list provides this
>>> data).
>>>
>>> There is no ROLE_LIST entitlement, and it appears that roles can be
>>> listed
>>> (in full detail) without any authentication or authorization. Although
>>> this doesn't break the use case above, it doesn't seem that roles should
>>> be
>>> listable without authn/authz. Again this is inconsistent with ROLE_READ
>>> which is required to read a role by id, even though list provides the
>>> same
>>> detail.
>>>
>>
> There is already an issue opened for changing this (SYNCOPE-132) that also
> explains the rationale behind the current implementation.
>
> Some suggestions, or a starting point for discussion:
>>>
>>> 1. Change USER_LIST to permit listing of *ALL* users (regardless of
>>> roles).
>>> 2. Create ROLE_LIST, and make it required to list roles.
>>> 3. Allow USER_LIST in all places where USER_READ+ROLE_x is required
>>>
>>> (i.e. USER_LIST is a superset of USER_READ).
>>> 4. Require USER_UPDATE+ROLE_x entitlement to add/delete role "x" from
>>>
>>> a user.
>>>
>>> I'm not sure the above mods are the correct approach. These suggestions
>>> still leave a bit of ambiguity, and likely conflict with the needs for
>>> other use cases. However, I think the use case where "the Manager" who
>>> is
>>> permitted to control the membership of a sub-set of roles is quite
>>> common.
>>> With the above, the following example should work (names used instead
>>> of
>>> numbers for clarity):
>>>
>>> Role "foo-mgr" has entitlement "USER_LIST, USER_READ, USER_UPDATE,
>>> ROLE_LIST, ROLE_READ, ROLE_foo1, ROLE_foo2".
>>> User "themgr" has role "foo-mgr"
>>> User "joe" has role "bar1".
>>> Then, "themgr" can log in, find "joe" and add (or remove) "joe" from the
>>> "foo1" and/or "foo2" roles.
>>>
>>> However, "themgr" cannot remove "joe" from "bar1" (because "themgr" does
>>> not have the "ROLE_bar1" entitlement).
>>>
>>
> [1] https://cwiki.apache.org/**confluence/display/SYNCOPE/**
> Authentication+and+**authorization<https://cwiki.apache.org/confluence/display/SYNCOPE/Authentication+and+authorization>
> [2] https://issues.apache.org/**jira/browse/SYNCOPE-225<https://issues.apache.org/jira/browse/SYNCOPE-225>
> [3] https://svn.apache.org/repos/**asf/syncope/branches/1_1_X/**
> core/src/main/java/org/apache/**syncope/core/security/**
> SyncopeUserDetailsService.java<https://svn.apache.org/repos/asf/syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/security/SyncopeUserDetailsService.java>
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>
>
Re: Syncope User & Role entitlements (role management delegation)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 20/06/2013 22:55, James Flemer wrote:
> Hello,
>
> Any comments on these suggestions/discussion regarding roles and
> entitlements? I'd like some feedback from the core developers if this
> approach seems reasonable, and whether patches with these or similar
> changes might or might not be accepted into the project. Thanks!
Hi James,
sorry for the delay: busy period...
See my comments inline below.
Regards.
> On Mon, Jun 3, 2013 at 11:21 PM, James Flemer <ja...@ndpgroup.com>wrote:
>
>> Hi,
>>
>> I have a use case for role management delegation. The desired use case is:
>> A given user, "the Manager", is permitted to add and remove other users
>> from a set of one or more "managed roles", but is not permitted to modify
>> role membership for other roles.
Premise: the whole authorization is going to be refactored in Syncope
1.2.0 by introducing realms (see SYNCOPE-119 and related).
I understand that you have already read [1].
Have you also been playing with role ownership. introduced by [2] since
Syncope 1.1.0? I have just updated [1] with some basic information about
this.
Basically, an user or a role can be defined "owner" of another role
(this is similar to Active Directory's group owner).
Users owning role A (or members of a role owning role A) are
automatically granted entitlements ROLE_CREATE / ROLE_READ / ROLE_UPDATE
/ ROLE_DELETE + ROLE_A + ROLE_X where X is a descendant of A with
inheritOwner=true.
This is done at [3], lines 81:92.
Could you please try to re-think your use case with this information?
>> NOTE: All following comments apply to Syncope 1.1.0 / 1.1.x.
>>
>> The current USER_* and ROLE_* entitlements are somewhat confusing (perhaps
>> incomplete), and unfortunately do not support the use case above.
>>
>> The USER_LIST entitlement actually behaves like:
>> "allow listing all users who's set of roles is a subset of my role
>> entitlements"
>> In other words, a user (with USER_LIST) cannot see other users if they
>> have a role that the user does not have an entitlement to. I would have
>> expected that USER_LIST would allow listing of all users, or I would expect
>> another entitlement like USER_LIST_ALL to cover that case. The "list
>> users" capability is needed for the use case above, the manager needs the
>> ability to see all users.
Introducing a USER_LIST_ALL can indeed be an option.
>> The USER_UPDATE and USER_READ entitlements seems to be unconditional, they
>> are NOT limited according to Role as USER_LIST is. This is inconsistent.
This is not true: UserController#update(UserMod) and
UserController#read(username) are respectively bound to USER_UPDATE and
USER_READ by Spring Security annotations *and* checked against role
operational entitlements.
More generally, any REST service that needs to access user details from
JPA store is checked against this.
>> Additionally, USER_LIST and USER_READ are somewhat overlapping. Listing
>> user includes all the detail in USER_READ. However, USER_LIST doesn't
>> allow reading user by id or username (even though list provides this data).
>>
>> There is no ROLE_LIST entitlement, and it appears that roles can be listed
>> (in full detail) without any authentication or authorization. Although
>> this doesn't break the use case above, it doesn't seem that roles should be
>> listable without authn/authz. Again this is inconsistent with ROLE_READ
>> which is required to read a role by id, even though list provides the same
>> detail.
There is already an issue opened for changing this (SYNCOPE-132) that
also explains the rationale behind the current implementation.
>> Some suggestions, or a starting point for discussion:
>>
>> 1. Change USER_LIST to permit listing of *ALL* users (regardless of
>> roles).
>> 2. Create ROLE_LIST, and make it required to list roles.
>> 3. Allow USER_LIST in all places where USER_READ+ROLE_x is required
>> (i.e. USER_LIST is a superset of USER_READ).
>> 4. Require USER_UPDATE+ROLE_x entitlement to add/delete role "x" from
>> a user.
>>
>> I'm not sure the above mods are the correct approach. These suggestions
>> still leave a bit of ambiguity, and likely conflict with the needs for
>> other use cases. However, I think the use case where "the Manager" who is
>> permitted to control the membership of a sub-set of roles is quite common.
>> With the above, the following example should work (names used instead of
>> numbers for clarity):
>>
>> Role "foo-mgr" has entitlement "USER_LIST, USER_READ, USER_UPDATE,
>> ROLE_LIST, ROLE_READ, ROLE_foo1, ROLE_foo2".
>> User "themgr" has role "foo-mgr"
>> User "joe" has role "bar1".
>> Then, "themgr" can log in, find "joe" and add (or remove) "joe" from the
>> "foo1" and/or "foo2" roles.
>>
>> However, "themgr" cannot remove "joe" from "bar1" (because "themgr" does
>> not have the "ROLE_bar1" entitlement).
[1]
https://cwiki.apache.org/confluence/display/SYNCOPE/Authentication+and+authorization
[2] https://issues.apache.org/jira/browse/SYNCOPE-225
[3]
https://svn.apache.org/repos/asf/syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/security/SyncopeUserDetailsService.java
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Syncope User & Role entitlements (role management delegation)
Posted by James Flemer <ja...@ndpgroup.com>.
Hello,
Any comments on these suggestions/discussion regarding roles and
entitlements? I'd like some feedback from the core developers if this
approach seems reasonable, and whether patches with these or similar
changes might or might not be accepted into the project. Thanks!
Regards,
-James
On Mon, Jun 3, 2013 at 11:21 PM, James Flemer <ja...@ndpgroup.com>wrote:
> Hi,
>
> I have a use case for role management delegation. The desired use case is:
> A given user, "the Manager", is permitted to add and remove other users
> from a set of one or more "managed roles", but is not permitted to modify
> role membership for other roles.
>
> NOTE: All following comments apply to Syncope 1.1.0 / 1.1.x.
>
> The current USER_* and ROLE_* entitlements are somewhat confusing (perhaps
> incomplete), and unfortunately do not support the use case above.
>
> The USER_LIST entitlement actually behaves like:
> "allow listing all users who's set of roles is a subset of my role
> entitlements"
> In other words, a user (with USER_LIST) cannot see other users if they
> have a role that the user does not have an entitlement to. I would have
> expected that USER_LIST would allow listing of all users, or I would expect
> another entitlement like USER_LIST_ALL to cover that case. The "list
> users" capability is needed for the use case above, the manager needs the
> ability to see all users.
>
> The USER_UPDATE and USER_READ entitlements seems to be unconditional, they
> are NOT limited according to Role as USER_LIST is. This is inconsistent.
> Additionally, USER_LIST and USER_READ are somewhat overlapping. Listing
> user includes all the detail in USER_READ. However, USER_LIST doesn't
> allow reading user by id or username (even though list provides this data).
>
> There is no ROLE_LIST entitlement, and it appears that roles can be listed
> (in full detail) without any authentication or authorization. Although
> this doesn't break the use case above, it doesn't seem that roles should be
> listable without authn/authz. Again this is inconsistent with ROLE_READ
> which is required to read a role by id, even though list provides the same
> detail.
>
> Some suggestions, or a starting point for discussion:
>
> 1. Change USER_LIST to permit listing of *ALL* users (regardless of
> roles).
> 2. Create ROLE_LIST, and make it required to list roles.
> 3. Allow USER_LIST in all places where USER_READ+ROLE_x is required
> (i.e. USER_LIST is a superset of USER_READ).
> 4. Require USER_UPDATE+ROLE_x entitlement to add/delete role "x" from
> a user.
>
> I'm not sure the above mods are the correct approach. These suggestions
> still leave a bit of ambiguity, and likely conflict with the needs for
> other use cases. However, I think the use case where "the Manager" who is
> permitted to control the membership of a sub-set of roles is quite common.
> With the above, the following example should work (names used instead of
> numbers for clarity):
>
> Role "foo-mgr" has entitlement "USER_LIST, USER_READ, USER_UPDATE,
> ROLE_LIST, ROLE_READ, ROLE_foo1, ROLE_foo2".
> User "themgr" has role "foo-mgr"
> User "joe" has role "bar1".
> Then, "themgr" can log in, find "joe" and add (or remove) "joe" from the
> "foo1" and/or "foo2" roles.
>
> However, "themgr" cannot remove "joe" from "bar1" (because "themgr" does
> not have the "ROLE_bar1" entitlement).
>
>
> Regards,
>
> James Flemer
>