Custom Editor and Author Setup

The Default Author / Editor Setup page explains how the standard author and editor groups are configured and what permissions they have. This page outlines best practices for configuring custom setups, such as creating a group of editors with access limited to specific content areas.

For a complete example, see Grant Access to One Channel. This example can also be adapted to restrict access to a specific subfolder, as described in Set Permissions on Folders. This page provides general guidelines for implementing restricted access for custom groups rather than a step-by-step example.

Custom Security Domains

Prerequisites

To restrict access for specific groups or users to certain content areas, you must create custom security domains. Before proceeding, review the following documentation:

It is important to understand the following:

When configuring custom security domains, use the Console to review user permissions on specific nodes. This feature is available in version 14.0.0 and later. See View Permissions of a User in the Console for details.

Important: Security domains are part of the configuration (except for some system properties).

For more information about configuration categories, see Configuration vs Content (vs System). Because security domains are configuration, ensure that any changes are included in your local bootstrap configuration. If not, new deployments may remove custom domains, domain rules, or auth roles.

If a CMS user has the xm.security.application-admin userrole, they can modify auth roles within security domains at runtime, such as through the CMS UI (Setup > System > Permissions). However, these changes should also be made by a developer with auto-export enabled to ensure they are included in the bootstrap configuration. If changes are made directly in production, reconcile them into the bootstrap configuration before the next deployment. Use the Configuration Verifier to assist with this process.

Best Practices for Custom Security Domains

The Default Author / Editor Setup uses the Userrole xm.default-user.author and xm.default-user.editor. These roles grant hippo:author and hippo:editor privileges for all nodes under /content via the /hippo:configuration/hippo:domains/content domain. Common content access scenarios include:

Denying access to a specific folder (for example, for authors)
Creating a group of authors or editors with access only to a specific part of the content

You do not need to create custom Userroles for these scenarios. Use the existing userroles and create custom groups that do not have the global xm.default-user.author or xm.default-user.editor roles. For more details, see Deny Access to a Folder and Grant Access to One Channel (also covered in Set Permissions on a Folder).

In these examples, the recommended approach is to use existing userroles, create new groups, and assign those groups the appropriate userroles for their required functional or feature access (these do not grant repository node privileges). For example:

xm.cms.user, xm.content.user, xm.report.user, xm.dashboard.user

Assign these roles to a group of users who need to log in to the CMS and access the content, report, and dashboard perspectives. This group will not have access to the Experience Manager.

Next, create new Security Domains for specific content areas and assign the new group the author or editor role as needed. For example:

/content-subfolder:
  jcr:primaryType: hipposys:domain
  /content-domain:
    jcr:primaryType: hipposys:domainrule
    /content-and-descendants:
      jcr:primaryType: hipposys:facetrule
      hipposys:equals: true
      hipposys:facet: jcr:path
      hipposys:type: Reference
      hipposys:value: /content/documents/subfolder
  /author:
    jcr:primaryType: hipposys:authrole
    hipposys:groups: [mygroup-authors]
    hipposys:role: author
    hipposys:users: []
  /editor:
    jcr:primaryType: hipposys:authrole
    hipposys:groups: [mygroup-editor]
    hipposys:role: editor
    hipposys:users: []

Introducing Custom Userroles

If you need to assign cross-cutting functionality (for example, a group of users who are editors for a specific content folder and webmasters for a subset of channels), consider creating new userroles. This approach is useful for dynamic groups: instead of adding each new group to every relevant security domain, assign a userrole to the group and reference that userrole in the security domains.