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 <james.fle...@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/
