Prevent users to create / edit / remove other users with higher security permissions

Problem

Inspiration: https://www.cuba-platform.com/discuss/t/standard-user-issue/10648/3 Also described problem was discussed in Sherlock some time ago.

As far as I know, in CUBA currently there is no built-in prevention for a non-administrator User to create a new user with more permissions than he/she has, e.g. with administrative permissions.

Therefore if you want to be reliably secure, in CUBA you should give the access to Create or Edit new Users only to administrators, never to limited users.

Of course this is not convenient for large deployments where non-sysadmin managers exists. And probably no one properly limits users this way in production deployments. Workarounds are possible but inconvenient.

Another thing: SuperUser role has access to everything including JMX Console, Groovy reports, admin-tools etc. - functions that should be allowed only to sysadmin. In companies where "manager" and "sysadmin" roles are separated this creates a collision. The only person who should have access to creating new users is a sysadmin??? Otherwise the manager can elevate its own rights to a sysadmin and gain access to the server.

Suggestion

Validation

CUBA security subsystem should validate: what level of permissions can be assigned to users A, B, C that are created or edited by the user D. 1) If user D creates new user A - user A should not get "higher permissions" then his/her creator D. 2) If user D edits user B and changes his/her roles or group - new B's permissions should not be "higher" than D's permissions. 3) If user D edits user C and old C's permissions are "higher" than D's permissions - then D should not be able to edit C's security settings (roles and group) (or even all settings?). 4) User D can not edit his/her own permissions when not being an superuser.

Definition of "higher permissions"

Note that security settings in CUBA are a combination of roles and access group.

Discussable point - how we determine "higher permissions"? My vision: 1) User having a Super role is higher than non-superusers. 2) Super-user is the same level as other super-user. 3) Calculate total aggregated User's permissions (sec$Permission). If A has at least one permission that B doesn't have - then B can not edit A. It can happen that both A and B can not edit each other. Example: A is a "accounting manager" and B is a "driver liason manager". A can create/edit accounting users but can't create/edit driver liason users. And visa versa.

4) Access groups - not sure here. Probably a group hierarchy should be used. User A should be able to use only his/her own access group or the group which is descendant of that group.

5) Add a specific permission "Edit user security settings disregarding permission boundaries". The bearer of this permission can violate all above rules without being a super-user, if for some weird reason it is required.

Of course, all non-administrator users should be disallowed (with runtime or design-time roles) to create/edit Role entities, otherwise above rules can be avoided.

This User attributes and actions should also be considered as security settings:

login
password,
active flag
substituted users
permitted IP mask
User browser: Remove action, password and token related actions
Group browser -> Move to Group action
Roles browser -> Assign to users action

Alternative approach from AWS

We can take alternative approach like implemented in AWS. The following link shows how AWS IAM solves the same problem by using "permission boundaries" and conditional permissions: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html?icmpid=docs_iam_console

Shortly:

we create separate role which serves as a "permission boundary".
somehow we attach this role to user D as a "delegated permission boundary" specifying that he/she can create/edit/remove users but is limited with that boundary. That is:
Permissions of users created by D will be limited by the boundary
D can edit/remove only those users whose permissions are "less than or equal" the boundary
D can not assign more permissions to any users whose permissions are "more than" given boundary

cuba-platform / cuba