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 <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. > > 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 >
