Security Configuration Overhaul

This document describes the significant overhaul of the Security Configuration for Bloomreach Experience Manager 14.0.0 and the rationale behind it.

Rationale

The Security Configuration in Bloomreach Experience Manager 14.0.0 has significantly changed to make common use cases much easier to achieve, such as

• Excluding a single folder from access for a group of CMS users
• Supporting different users / groups for specific parts of the content sets
• Allowing specific users / groups to log in into the CMS and/or Console application
• Toggling visibilities of perspectives on/off per user or group of users
• Configure a Security Domain next to the data it is about (Federated Security Domain)
• Improve usability of the author role in the CMS
• Supporting functional (user) roles for delivery tier user authorization
• Privilege based protected REST endpoints

What Changed

Before reading the sections below, best to first read through the Security chapter for version 14.0.0. If you were already familiar with the Security Configuration, at least make sure that you read Userroles which is a new concept in 14.0.0 and read Security Domains again and be aware about the extremely useful tool View Permissions of a User in the Console.  

By-catch of the security model revamp has been very many improvements under the hood, such as a much more performant processing of access management checks, much less (configuration) read access required for CMS users, no more implicit read access on child nodes of document variants, a very much smaller initial configuration setup resulting in a more lightweight login and a much smaller authorization query resulting in a more lightweight authorized search and much more.

Default Authorization Setup Overhaul

At Default Authorization Setup it is described how the default bootstrapped authorization setup is in version 14.0.0. This is very much different from versions before 14.0.0. The amount of domains configured below /hippo:configuration/hippo:domains has more than halved, and the total amount of hipposys:domainrule below domains have been almost divided by 4! Also 14.0.0 by default bootstraps Federated Security Domains. These are domains which are stored next to the data they configure authorization for, see Security Domains. 

The new Security Domain configuration setup is almost completely hierarchical constraint based, whereas before version 14.0.0, the setup was mostly Node aspect (property) based. In 14.0.0, most Security Domains have a constraint by jcr:path, for example something like

/content-and-descendants:
  jcr:primaryType: hipposys:facetrule
  hipposys:equals: true
  hipposys:facet: jcr:path
  hipposys:type: Reference
  hipposys:value: /content

matching /content and all descendant nodes. Since most domains are now setup with hierarchical constraints, version 14.0.0 also now support implicit ancestry read access.

Implicit Ancestry Read Access

Before version 14.0.0, when for example having a facetrule (aka which nodes match) like this:

/my-sub-content:
  jcr:primaryType: hipposys:facetrule
  hipposys:equals: true
  hipposys:facet: jcr:path
  hipposys:type: Reference
  hipposys:value: /content/documents/myproject/sub/subsub

then in version 13.4 and before, there had to be configured separate domains to make sure that every ancestor was readable. In version 14.0.0, we introduced implicit read access making this much easier, also see Security Domains.

Support Security Constraints on Boolean, Long or Double properties

Before version 14, it was not possible for Facet Rules to filter / secure documents based on properties of type boolean, long or double. With version 14 this is now supported.

Delivery Tier Bootstraps Required Users and Groups

Before Bloomreach Experience Manager 14.0.0, an archetype created project had a set of configuration files containing required delivery tier users and groups, such as groups liveusers, previewusers, etc and users such as liveuser, previewuser, etc. All configuration files below repository-data/application/src/main/resources/hcm-config/security initially created by the archetype have become redundant since they are all bootstrapped now by the delivery tier (and by webfiles). Also there are no groups needed or used any more for the delivery tier users, so the groups liveusers, previewusers, configusers and sitewriters are not bootstrapped any more.

Changed Default Authorization of an Author

Before Bloomreach Experience Manager 14.0, an author in the CMS was not allowed to delete, move, rename or copy offline documents. It could only request a deletion for an offline document (apart from of course request publication). This made the author role too constraint, since for example an author could not even delete or rename a document (s)he had just created. Having a typo in the name during creation could only be fixed by an editor since an author could not rename a document. 

Since version 14.0.0, with respect to the content editing perspective, authors and editors have pretty much the same privileges except that an author cannot changes the live version of a document directly: It cannot (schedule) publish documents or take them offline , but only request a (scheduled) publish or take offline. 

The above changes make the author role much more usable

Changed Editor Privileges

Before Bloomreach Experience Manager 14.0, an editor by default had jcr:write privilege on folders and all document variants. In Bloomreach Experience Manager 14.0, this has been corrected, since only jcr:write is required on the draft document variant of which the editor is holder. All other changes that an editor makes to content, like adding folders, publishing a document, etc do not require jcr:write since these changes are delegated to the workflow session which has the required privileges to be able to perform the required actions. This means that if you have for example custom java code modifying JCR Nodes using the session of a CMS user like an editor, this might no longer work automatically in Bloomreach Experience Manager 14.0. You can get it working again by either delegating the invocations to an impersonated workflow session, or again add jcr:write to certain nodes for editors (which is disadviced though).

Read/write access to own user/group(s) nodes dropped

Default read/write access from (your own) user/group(s) has been dropped for logged in users (other than admins). Changing a user its password programatically now requires using a dedicated ChangePasswordManager API, available from the new RepositorySecurityManager via the HippWorkspace.

Changed Sitewriter Privileges

The sitewriter is a delivery tier user primarily used for being able to persist form data below /formdata. Since version 14.0.0 the only privilege a sitewriter by default has is readwrite on /formdata and descendants. It doesn't have any other privilege, so it cannot even read any JCR Node other than below /formdata. Before 14.0.0, the sitewriter had quite some jcr:read access, for example on folders, hippo:log, hippo:configuration and another bunch of nodes. If you rely on workflow invocations by the sitewriter user, the way to achieve this has completely changed compared to version before 14.0.0. It has become much simpler as is documented at Set Permissions When Using Workflow in the Delivery Tier. You will need to redo the logic if you invoke workflow with the sitewriter user.

Delivery Tier Authorization

The Delivery Tier supports Authentication and Authorization. The authentication itself is pretty backward compatible with pre 14.0.0 setups, however, the  Authorization configuration has been made more logical and changed as a result. The new way how it works is documented at Configure the RepositoryAuthenticationProvider. If you have Site Login support combined with authorization, you most likely must take action to align the setup with version 14.0.0.

Repository Servlet Access

The Repository Servlet used to be accessible by any user that was able to authenticate. Since version 14.0.0, the Repository Servlet is only accessible for users with the functional (feature) userrole xm.repository-browser-user, see  Access to CMS, Console, Repository.