Default Repository Authorization Setup

Overview

This page describes the default repository authorization configuration in Bloomreach Content. It explains which user roles have which permissions within each default security domain. This information applies to a standard project created with the project archetype.

For background on the authorization model, see Authorization Model Concepts. For guidance on customizing the default setup, refer to Authentication and Authorization Walkthroughs.

This page focuses on repository-level authorization. It does not cover feature user roles (such as *xm.<feature>.user*) described in User Roles, as those do not grant repository privileges. The following sections detail the default security domains, specifying which user roles are granted which permissions.

Note: The default security domains primarily use user roles to define access. The hipposys:groups and hipposys:users properties are typically reserved for custom security domains.

CMS/Repository Default Security Domains

All domains described in this section are located under /hippo:configuration/hippo:domains.

Domain: content

The content domain applies to all nodes at and below /content. It uses the following user roles and permissions:

User Role	Permission
`xm.content.admin`	`admin`
`xm.content.author`	`author`
`xm.content.editor`	`editor`
`xm.content.viewer`	`readonly`

Domain: everywhere

The everywhere domain matches all nodes throughout the repository.

User Role	Permission
`xm.repository.admin`	`admin`
`xm.repository.reader`	`readonly`

Domain: frontend-config

The frontend-config domain grants readonly privileges to users with the xm.frontend-config.reader user role for the following paths and their descendants:

/hippo:configuration/hippo:frontend
/hippo:namespaces
/hippo:configuration/hippo:queries
/hippo:configuration/hippo:workflows

Typically, only CMS and Console users require read access to these nodes. The xm.cms.user and xm.console.user roles inherit xm.frontend-config.reader. For details, see User Roles.

Domains: draft-document-holder-readwrite and non-publishable-readwrite

These two domains address specific write access requirements for editors and authors.

Since version 14.0.0, editors and authors have minimal direct jcr:write privileges. Most actions, such as publishing or creating documents, are performed through the workflow session, which has elevated privileges. The editor session only determines whether a user can invoke workflow actions.

However, editors and authors need direct write access in these cases:

When editing a draft document they hold.
When editing image or asset documents.

To support these scenarios:

The draft-document-holder-readwrite domain grants jcr:write (and read) privileges to any user who is the holder of a draft document. Only users who become holders through a workflow action can write to the draft.
The non-publishable-readwrite domain allows CMS users to update imagesets and assets. These documents are not publishable and do not use workflow, so there is no holder. The domain matches all nodes that meet the following criteria:
1. Located under /content
2. Are documents
3. Are not publishable

The domain uses a facetrule to match documents with hippo:availability = live:

/documents-only:
  jcr:primaryType: hipposys:facetrule
  hipposys:equals: true
  hipposys:facet: hippo:availability
  hipposys:type: String
  hipposys:value: live

A nodetype constraint on hippo:document is not sufficient because hippostd:folder and hippostd:directory also extend from hippo:document.

For the non-publishable-readwrite domain:

User Role	Permission
`xm.content.author`	`readwrite`

Domain: security-user-management

The security-user-management domain applies to all nodes at and below /hippo:configuration/hippo:groups and /hippo:configuration/hippo:users.

User Role	Permission
`xm.security.viewer`	`readonly`
`xm.security.user-admin`	`readwrite`

By default, users with the xm.default-user.cms-admin or xm.default-user.system-admin roles have readwrite access to all groups and users.

Domain: defaultread / versioning

These domains grant read access to certain JCR nodes for all users. End projects should not modify these domains.

Domain: autoexport-config

This domain allows the Console user to modify the auto-export configuration, enabling or disabling it as needed.

Webfiles Domain

Webfiles are stored under /webfiles in the repository. The webfiles security domain is configured as a Federated Security Domain at /webfiles/webfiles:domains/webfiles. It grants jcr:read privileges to all nodes under /webfiles, except /webfiles/webfiles:domains, for users with the xm.webfiles.reader role.

As a result, the HST liveuser and previewuser, as well as users with the xm.channel.viewer role (such as editors and authors), can read webfiles.

HST Default Security Domains

The delivery tier (HST) includes security domains required by internal HST users for rendering requests. There are two main domains—live-documents and preview-documents—located under /hippo:configuration/hippo:domains, along with federated domains that are project-specific.

Domain: live-documents

The live-documents domain, located under /hippo:configuration/hippo:domains, grants jcr:read privileges to the HST liveuser for all nodes under /content, except /content/attic and nodes where hippo:availability is not live. This allows liveuser to read all folders and live documents.

Domain: preview-documents

The preview-documents domain functions like live-documents, but for the previewuser. It excludes documents where hippo:availability is not preview.

Domain: formdata

The formdata domain is configured at /formdata/hst:domains/formdata. It matches all nodes under /formdata, except /formdata/hst:domains. Users with the xm.form.writer role, such as the HST sitewriter, receive the readwrite permission.

Domain: hstconfig

The hstconfig domain is configured at:

/hst:myproject/hst:domains/hstconfig

Replace myproject with your project name. This domain defines which user roles have which permissions for a specific channel. It matches all nodes under /hst:myproject, except /hst:myproject/hst:domains.

The following roles are assigned:

User Role	Permission
`xm.channel.admin`	`channel-admin`
`xm.content.webmaster`	`channel-webmaster`
`xm.content.viewer`	`channel-viewer`

channel-viewer: Allows a CMS user to view a channel.
channel-webmaster: Allows a user to modify a channel and publish their own changes.
channel-admin: Allows a user to modify and publish both their own and others' changes.

By default:

The admin user, and the admin and cms-admin groups, have the xm.channel.admin role.
The webmaster group (/hippo:configuration/hippo:groups/webmaster) has the xm.content.webmaster role.
The editor and author groups have the xm.channel.viewer role.

Relevance Default Security Domain

The Relevance Module (formerly Targeting) configures its security as a federated domain at /targeting:targeting/targeting:domains/targeting. This domain matches all nodes under /targeting:targeting, except /targeting:targeting/targeting:domains and its descendants.

Roles assigned:

User Role	Permission
`xm.targeting.editor`	`targeting-editor`
`xm.targeting.viewer`	`targeting-viewer`

targeting-viewer: (Not yet implemented) Will provide read-only access to the Relevance dashboard.
targeting-editor: Grants read access to the Relevance dashboard and jcr:write privileges for /targeting:targeting and its descendants.

See User Roles for inheritance details.

Projects Default Security Domain

The Projects Module configures its security as a federated domain at /hippowpm:hippowpm/hippowpm:domains. It matches all nodes under /hippowpm:hippowpm/hippowpm:projects.

Roles assigned:

User Role	Permission
`xm.project.admin`	`project-admin`
`xm.project.editor`	`project-editor`
`xm.project.viewer`	`project-viewer`

Refer to User Roles for descriptions and inheritance relationships.

Plugins Default Security Domains

The Poll Plugin uses /polldata in the repository as its storage location. The polldata security domain is configured as a Federated Security Domain and is created when the Poll Plugin is installed. It is located at /polldata/poll:domains/polldata and matches all nodes under /polldata, except /polldata/poll:domains.

Roles assigned:

User	Permission
`sitewriter`	`readwrite`
`liveuser, previewuser`	`readonly`