Implement user roles and support using them for decoupling security domains from user and groups

User roles are a new element in the security model which can be assigned to users and groups to represent a functional capability or responsibility of a user which is not, or not directly, related to specific repository content.

To be able to secure such capabilities or responsibilities, like being allowed to login or see/use a particular feature like the admin perspective, we required (mis)using specific a data role (Security Domain AuthRole) for specific repository content (Security Domain Facet Rule) and then executing a 'JCR' permission check through Session.hasPermission(path, action). Most of these 'not-data-related' checks and their needed underlying security domain configuration, use or need a rather arbitrary chosen and difficult to maintain or customize setup.

Preferably, such non-data-related security checks should be possible using something like a

  boolean isUserInRole(String roleName)

call, which is commonly provided in other security frameworks and specifications, without need for a specific repository context to configure or permission evaluation.

This issue introduces this new User Role feature, as well as provide support for using it to further simplify the configuration and management of our security domain authorizations (Security Domain AuthRoles).

A new security configuration element User Role is introduced which is separate from, but akin to, the existing Role element:

[hipposys:userroles] > nt:base
- hipposys:userroles (string) multiple
- hipposys:system (boolean)

[hipposys:userrolesfolder] > nt:base
+ * (hipposys:userrole) = hipposys:userrole

[hipposys:securityfolder] > nt:base
...
- hipposys:userrolespath (string) mandatory

[hipposys:configuration] > nt:base
...
+ hippo:userroles (hipposys:userrolefolder) = hipposys:userrolefolder

[hipposys:user] > nt:base
...
- hipposys:userroles (string) multiple

[hipposys:group] > nt:base
...
- hipposys:userroles (string) multiple

The above additions to the security node type definitions (hipposys.cnd) make it possible to:

• define userroles, with the ability to include or imply other userroles through its hipposys:userroles string property (similar to hipposys:role)
• assign userroles (by name) to users and groups

The userroles of a logged in user will be loaded (only) during login, and then can be checked via:

  boolean HippoSession.isUserInRole(final String userRoleName)

In addition to this, the configuration of the Security Domains AuthRole element is enhanced to also allow referencing a user role, besides, or instead of, users or groups:

[hipposys:authrole] > nt:base
 - hipposys:role (string) mandatory
 - hipposys:users (string) multiple
 - hipposys:groups (string) multiple
 ...
 - hipposys:userrole (string)

With the above enhancement Security Domain definitions now can be decoupled from directly configuring specific users or groups, which can greatly improve maintainability and reduce, or even fully remove, the need to customize Security Domain authorizations.
By using only pre-defined user roles ('owned' by product or project developers) in Security Domain AuthRole definitions, security authorizations then can be fully managed through assigning (or removing) the corresponding user roles to specific users or groups.

This decouples the definition and maintenance of the more low-level technical security domain model, done by developers or at runtime by product configuration managers, from operational security management done by user managers who only are or need to be responsible for the functional assignment of specific user roles to users and groups.

Furthermore, because user roles can be configured to include or imply other user roles, like xm-content-editor implies xm-content-author, user roles can be used more effective and efficient, instead of having to add users to multiple groups to achieve a similar result.

Important note: A hipposys:authrole can intentionally only reference a single hipposys:userrole, in contrast to multiple users or groups.
As a best practice this should not be limitating because the (single) user role name should more appropriately reflect the functional capability or responsibility the target users or groups should have.
It still remains possible though to define multiple hipposys:authrole nodes for one Security Domain granting the same hipposys:role, as long as the names of the hipposys:authrole nodes are different. For specific cases this may remove the need for introduce additional aggregating user roles, if needed.

Last but not least, with the ability to use user roles for AuthRoles, this now also allows renaming, re-purposing or even deleting default provided groups like admin, author, editor and webmaster, because they no longer are or need to be used and referenced in the default provided Security Domains.
Instead, only their corresponding new user roles xm-admin, xm-content-author, xm-content-editor and (to be added later) xm-webmaster are or can be used.
These groups are still provided by default but now initially empty, with each having their corresponding user role assigned. And any new group can be used and configured similarly, with the appropriate user role(s) assigned, without need to customize and maintain the, sometimes multiple, Security Domain AuthRoles.

So far the following pre-defined (system) user roles are provided (see also the new SecurityConstants class) and used by the repository and its Security Domain configurations:

• xm-admin: directly assigned to the admin and workflowuser users, and the default admin group (which is now empty by default)
• xm-content-reader: provides read-only access to content folders and documents, not default assigned (yet)
• xm-content-author: assigned to the default author group, implies xm-content-reader
• xm-content-editor: assigned to the default editor group, implies xm-content-author

Furthermore there are a few additional related API changes in HippoSession:

• The User and Group interfaces used and exposed by the (and already refactored, see REPO-2233) SecurityService now both have an additional
  Set<String> getUserRoles() method, returning the directly assigned user roles to respectively a user or group.
• HippoSession.getUser() now returns a SessionUser object, which interface extends User, but with an override of the Set<String> getUserRoles() method to return the resolved user roles of the current logged in session user. These resolved user roles only include the actually existing user roles, as well as their implied user roles. For example if a user has the xm-content-editor user role assigned, then also the xm-content-author user roles will be returned, but an assigned but not existing user role name foo will not be returned.
• The HippoSession.isUserInRole(String userRoleName) method therefore can and will effectively delegate to getUser().getUserRoles().contains(userRoleName).
• The methods boolean HippoSession.isSystemUser() and boolean HippoSession.isAnonymousUser() have been added, as for system or anonymous sessions HippoSession.getUser() will throw an ItemNotFoundException. For these type of sessions HippoSession.isUserInRole(anyRoleName) will always return true or false, respectively.