Introduce new userroles for security management, separating user (including group) security management from application security management

The current admin perspective in the CMS provides plugin applications for managing users, groups and permissions, as well as a few other admin-only applications like the (groovy) updater and system info/properties plugins.

Configuration wise this perspective (and sometimes one/more of the contained plugins) are 'protected' using rather complex domain security rules, to 'hide' them for anyone but admin users.

As this would be a perfect candidate to replace with userrole based protection, given that this type of access protection is (only) on functional level, not data level, I did some digging in the CMS plugin loader process and found out there is a very elegant and easy way to intercept the loading of plugins based on a isUserInRole check (e.g. using userroles) in the ClusterControl class.

The ClusterControl class is responsible for starting plugins for a plugincluster.
And also can 'handle' non-behaving plugins, e.g. those which do not start properly.
Those plugins simply are 'skipped', without breaking the process of other plugins (at least: as long as other plugins/services don't depend on them).

So, wiring a security check within this process is actually pretty simple and effective: if a user is not allowed to use a specific plugin, e.g. isUserInRole(<some userrole>) == false, then simply don't start that plugin.

To configure such a security check, just as some configuration property (e.g. hipposys:userrole: <some userrole>) on the plugin configuration node itself.
For example, to require the xm-admin userrole to start/show the admin perspective, only requires adding the property hipposys:userrole: xm-admin to be added:

      /adminLoader:
        jcr:primaryType: frontend:plugin
        cluster.name: cms-admin
        plugin.class: org.hippoecm.frontend.plugins.cms.admin.AdminPerspective
        hipposys:userrole: xm-admin

But now, we can do more!
Often, more and more refined separation of responsibilities is needed (or at least asked) for administrative and especially security related management.
This now becomes trivial to setup and configure, and for which (for now) 3 more userroles will be introduced (via the repository project):

• xm-security-user-manager: for managing users and groups, their group memberships and (new, to be added shortly) granted userroles.
  This userrole will also grant readwrite access to all users and groups through new domain definition security-user-management.
• xm-security-application-manager: for managing (if needed) user, group, and/or userrole authorizations within domains (permissions plugin), as well as managing (custom) userroles (new, to be added shortly)
  This userrole will also grant readwrite access to all domains through new domain definition security-application-management.
• xm-security-manager: aggregate userrole implied by both xm-security-user-manager and xm-security-application-manager, which can be used for (minimal) check to check the security plugins
  This userrole will also grant readonly access to all users, groups and domains through the above mentioned new domain definition security-user-management and security-application-management

The xm-admin userrole then obviously must imply (include) both the xm-security-user-manager and xm-security-application-manager userrole.

And with this, we now can provide fine-grained and out-of-the-box security protection for the admin perspective and all its plugins, without needing to ever setup and configure the complex domain security rules for that purpose. It now merely requires granting one of these xm-security-*-manager userroles to a specific user or group.

The following /hippo:configuration/hippo:frontend plugins will now be protected and require the following userrole out-of-the-box:

• /cms-static/adminLoader: xm-security-manager ( AdminPerspective)
  • /cms/admin/users: xm-security-manager (ListUsersPlugin)
  • /cms/admin/groups: xm-security-manager (ListGroupsPlugin)
  • /cms/admin/permissions : xm-security-manager (PermissionsPlugin)
  • /cms/admin/systeminfo: xm-admin (SystemInfoPlugin)
  • /cms/admin/systemprops: xm-admin (SystemPropertiesPlugin)
  • /cms/admin/updater: xm-admin (UpdaterPanelPlugin)
• /cms/cms-browser/configurationTreeLoader: xm-admin (DocumentTypes editor)

Note that the ListUsersPlugin, ListGroupsPlugin and PermissionsPlugin are not protected by either the xm-security-user-manager or xm-security-application-manager userrole, but that is to allow such users to at least readonly access to them. Through CMS-12065 these plugins will be adjusted to provide only modify access (create/update/delete) when the user has those more specific xm-security-user-manager role (for ListUsersPlugin and ListGroupsPlugin) or the xm-security-application-manager (for the PermissionsPlugin, and new UserRolesPlugin).