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ò <ilgro...@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 <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<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/> > >
