Security Configuration Overhaul

This page outlines the major changes to the security configuration in brXM 14.0.0 and explains the reasoning behind these updates.

Rationale

In brXM 14.0.0, the security configuration has been redesigned to simplify common scenarios, including:

• Restricting access to specific folders for certain CMS user groups
• Assigning different users or groups to manage distinct sections of content
• Controlling which users or groups can access the CMS and/or Console applications
• Enabling or disabling perspectives for individual users or groups
• Defining a Security Domain adjacent to the relevant data (Federated Security Domain)
• Improving the usability of the author role in the CMS
• Supporting functional (user) roles for delivery tier authorization
• Protecting REST endpoints based on privileges

Summary of Changes

Before reviewing the details below, read the Security chapter for version 14.0.0. If you are familiar with previous security configurations, review the new Userroles concept and revisit Security Domains. The View Permissions of a User in the Console tool is also recommended for understanding permissions.

The security model overhaul includes several internal improvements, such as faster access management checks, reduced configuration read access for CMS users, removal of implicit read access on child nodes of document variants, a smaller initial configuration footprint, and more efficient authorization queries.

Default Authorization Setup Changes

The Default Authorization Setup in version 14.0.0 has been significantly revised. The number of domains under /hippo:configuration/hippo:domains has been reduced by more than half, and the number of hipposys:domainrule entries has been reduced by approximately 75%. Version 14.0.0 also introduces Federated Security Domains, which are stored alongside the data they govern. For details, see Security Domains.

The new configuration relies primarily on hierarchical constraints, rather than node property-based constraints. In most cases, security domains now use a jcr:path constraint, for example:

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

This configuration matches /content and all descendant nodes. With this hierarchical approach, version 14.0.0 now provides implicit ancestry read access.

Implicit Ancestry Read Access

Prior to version 14.0.0, when using a facetrule such as:

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

you needed to configure separate domains to ensure all ancestor nodes were readable. In version 14.0.0, implicit read access is granted to ancestor nodes, simplifying configuration. For more information, see Security Domains.

Security Constraints on Boolean, Long, or Double Properties

In previous versions, Facet Rules could not filter or secure documents based on boolean, long, or double properties. Version 14.0.0 adds support for these property types.

Delivery Tier Bootstraps Required Users and Groups

Before version 14.0.0, project archetypes generated configuration files for required delivery tier users and groups (e.g., liveusers, previewusers, liveuser, previewuser). These configuration files under repository-data/application/src/main/resources/hcm-config/security are now redundant, as the delivery tier and webfiles bootstrap these users and groups automatically. The delivery tier no longer requires or uses groups such as liveusers, previewusers, configusers, or sitewriters.

Updated Author Role Authorization

In versions prior to 14.0.0, CMS authors could not delete, move, rename, or copy offline documents. They could only request deletion or publication, which limited the role. For example, authors could not rename a document they had just created.

Starting with version 14.0.0, authors and editors share most content editing privileges. The key difference is that authors cannot directly change the live version of a document—they cannot publish, schedule publication, or take documents offline directly, but can request these actions.

These changes make the author role more practical for content editing tasks.

Updated Editor Privileges

Previously, editors had the jcr:write privilege on folders and all document variants. In version 14.0.0, editors only require jcr:write on the draft document variant they hold. Other content changes, such as adding folders or publishing documents, are handled by the workflow session, which has the necessary privileges.

If you use custom Java code that modifies JCR nodes with a CMS user's session (such as an editor), this may no longer work by default in version 14.0.0. To restore functionality, delegate these actions to an impersonated workflow session or grant jcr:write to specific nodes for editors (not recommended).

Removal of Read/Write Access to Own User/Group Nodes

By default, logged-in users (except administrators) no longer have read or write access to their own user or group nodes. To change a user or password programmatically, use the dedicated ChangePasswordManager class, available from the new RepositorySecurityManager via the HippoWorkspace in the Repository API.

Updated Sitewriter Privileges

The sitewriter user is intended for persisting form data under /formdata. In version 14.0.0, sitewriter only has read and write privileges for /formdata and its descendants. It cannot access any other JCR nodes. In previous versions, sitewriter had broader jcr:read access, including folders, hippo:log, hippo:configuration, and other nodes.

If your implementation relies on workflow invocations by the sitewriter user, you must update your logic for version 14.0.0. The revised approach is documented at Set Permissions When Using Workflow in the Delivery Tier.

Delivery Tier Authorization

The delivery tier supports both Authentication and Authorization. Authentication remains largely compatible with earlier versions, but authorization configuration has changed. For details, see Configure the RepositoryAuthenticationProvider. If your project uses site login with authorization, review and update your configuration for version 14.0.0.

Repository Servlet Access

Previously, any authenticated user could access the Repository Servlet. As of version 14.0.0, only users with the functional userrole xm.repository-browser-user can access the Repository Servlet. For more information, see Access to CMS, Console, Repository.