Custom Editor / Author Setup

At Default Author / Editor Setup you can read how the default author and editor groups behave and what they can do where. This document describes the current best practices to configure custom setups, for example a group of editors who are only editor on a subset of the content.

A completely worked out example is available at Grant Access to One Channel which also can be used to grant access to a certain subfolder only, see Set Permissions on Folders. Below follows not a worked out example, but more the common guidelines how to achieve restrained access to custom groups.

Custom Security Domains

Prerequisite

Requiring different groups / users to have, say, access to only a subset of the content starts with creating custom security domains. Before creating a new security domain however, make sure that you read

1. Security Domains
2. View Permissions of a User in the Console

Although also described at the end of Security Domains, we'll repeat here a very important section:

When working on custom security domains, it is very handy to view the permissions of a user on certain nodes via the Console. This feature is available since 14.0.0 and is documented at View Permissions of a User in the Console. Furthermore it is of paramount importance to realize that

This is very important to realize. See Configuration vs Content (vs System) for the difference between the categories. And because security domains are configuration, a developer has to make sure changes to the security domain configuration end up in local bootstrap. If not, on new deployments the custom domains, domain rules or auth roles can and will be deleted. 

If a CMS user has userrole xm.security.application-admin, that user can runtime modify auth roles within security domains, for example through the CMS UI (Setup > System > Permissions). Such changes typically should (also) be made as a developer with auto-export enabled to ensure they become part of the bootstrap configuration. When changes to security domains are (directly) needed and made in production, a developer has to make sure the production changes get reconciled into bootstrap configuration, for example by using the Configuration Verifier, before a next deployment which otherwise may destroy those changes.

Best Practice Custom Security Domain

The Default Author / Editor Setup are configured by using  the Userrole xm.default-user.author and xm.default-user.editor which result in hippo:author / hippo:editor privilege on everything below /content through the domain /hippo:configuration/hippo:domains/content. On content, there are typically two use cases which are addressed differently:

1. Deny access to a specific folder for for example authors
2. Create a new group of authors / editors who only have access to a part of the content

For the above two use cases you do not need to introduce custom Userroles. It can best be done with existing userroles and adding custom groups which do not have the global xm.default-user.author and xm.default-user.editor userroles. Use case 1 is described at Deny Access to a Folder and use case 2 is described at Grant Access to One Channel (same as Set Permissions on a Folder).

As can be seen in those examples, which cover most common use cases for specific author / editor permissions, you stick to using existing userroles and introduce new groups and assign those groups existing userroles for what the members of that group have as functional / feature roles (giving no repository nodes privilieges), for example

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

could typically be used for a group of users that need to be able to login into the CMS, and should be able to see the content, report and dashboard perspective. This group of users for example would not see the Experience Manager. 

Next to that, you then typically create new Security Domains for specific parts of the content, and assign the new group for example the role author or editor. For example something like

/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

When you have cross-cutting functionality, for example you have a group of users that are editor on a specific content folder and which are webmaster on a subset of the channels, you might want to introduce new userroles instead of specifying the groups on all different security domains. This is better when you have dynamic groups for example: When adding a new group, instead of having to add it to every security domain they need to be part of, you can set a userrole on that group (and the userrole is used in the security domains).