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

Reply via email to