Deny Access to a Folder

Important: YAML Configuration Walkthroughs

When following these walkthroughs, YAML configuration snippets are intended for import into a locally running repository using the Console with auto-export enabled. If you copy a YAML snippet directly into your project without auto-export, uncomment any lines like the following if present:

#.meta:category: system
#.meta:add-new-system-values: true

Auto-export automatically adds this meta information, but the Console's YAML import does not support *.meta* lines. You have two options:

Import the YAML snippet as-is into the Console with auto-export enabled.
Copy the YAML snippet into your project and uncomment the commented meta lines.

Overview

Objective

Restrict a group’s access to a specific folder in the content repository.

Scenario

This example uses a Bloomreach Experience Manager project created with the Maven archetype and the News feature added.

The project includes two root content folders:

/content/documents/myproject
Contains news articles.
/content/documents/administration
Contains resource bundles for static website labels.

By default:

The editor group has editor privileges on both folders.
The author group has author privileges on both folders.

This guide explains how to:

Deny the author group all access to /content/documents/administration.
Optionally, grant the author group read-only access to /content/documents/administration. This is useful if the administration folder contains documents like selection:valuelist that are used in pickers when editing other documents. In this case, authors need read access to selection list documents but must not be able to modify them.

Note

There are multiple ways to implement this use case. This guide documents the most straightforward approach. Depending on your requirements, you may choose to configure it differently, such as by introducing new groups or user roles.

Approach

To restrict access to the administration folder, update the Default Authorization Setup:

Exclude the administration folder from the default content domain at /hippo:configuration/hippo:domains/content.
Create a new domain /hippo:configuration/hippo:domains/content-administration that includes only the administration folder.
Assign the editor and admin groups the appropriate privileges on the content-administration domain.
Optionally, grant the author group read-only access to the content-administration domain.

Customizing Security Domains

Exclude the Folder from the Default Content Domain

Log in to the Console as admin.
Ensure Autoexport is enabled.
At /hippo:configuration/hippo:domains/content/content-domain, add a new facet rule named exclude-administration. You can use the following YAML snippet and import it on the content-domain node:

/exclude-administration:
  jcr:primaryType: hipposys:facetrule
  hipposys:equals: false
  hipposys:facet: jcr:path
  hipposys:type: Reference
  hipposys:value: /content/documents/administration

This additional facetrule ensures that the default /hippo:configuration/hippo:domains/content domain no longer matches /content/documents/administration or its descendants. As a result, users with the following user roles are affected:

xm.content.admin
xm.content.editor
xm.content.viewer

If you only apply the above configuration, the editors group will also lose access to /content/documents/administration, and the admin group will no longer have hippo:admin privilege for this folder (though admin can still read everywhere). To restore the correct privileges for /content/documents/administration, you must explicitly grant them to the relevant user roles.

Create a New Domain for the `administration` Folder

At /hippo:configuration/hippo:domains, add a new security domain with the following configuration:

/content-administration:
  jcr:primaryType: hipposys:domain
  /content-domain:
    jcr:primaryType: hipposys:domainrule
    /administration:
      jcr:primaryType: hipposys:facetrule
      hipposys:equals: true
      hipposys:facet: jcr:path
      hipposys:type: Reference
      hipposys:value: /content/documents/administration
  /editor:
    jcr:primaryType: hipposys:authrole
    hipposys:groups:
     #.meta:category: system
     #.meta:add-new-system-values: true
      type: string
      value: []
    hipposys:role: editor
    hipposys:userrole: xm.content.editor
    hipposys:users:
     #.meta:category: system
     #.meta:add-new-system-values: true
      type: string
      value: []
  /admin:
    jcr:primaryType: hipposys:authrole
    hipposys:groups:
     #.meta:category: system
     #.meta:add-new-system-values: true
      type: string
      value: []
    hipposys:role: admin
    hipposys:userrole: xm.content.admin
    hipposys:users:
     #.meta:category: system
     #.meta:add-new-system-values: true
      type: string
      value: []

After saving these changes, use the View Permissions Dialog in the Console to verify that:

An author user has no permissions or privileges on /content/documents/administration.
An editor user has the same permissions on /content/documents/administration as on /content/documents/myproject.

Optional: Grant Read-Only Access to Authors

If /content/documents/administration contains documents such as selection:valuelist that are required for pickers when editing documents under /content/documents/myproject, the author group may still need read access. The author group has the xm.content.viewer user role, which you can use to grant read-only access.

Add the following configuration to /hippo:configuration/hippo:domains/content-administration:

/readonly:
  jcr:primaryType: hipposys:authrole
  hipposys:groups:
    #.meta:category: system
    #.meta:add-new-system-values: true
    type: string
    value: []
  hipposys:role: readonly
  hipposys:userrole: xm.content.viewer
  hipposys:users:     
    #.meta:category: system
    #.meta:add-new-system-values: true
    type: string
    value: []

After making these changes, ensure all updates are synchronized with auto-export to your local project. Do not apply these changes directly to a production environment, as future deployments may overwrite them. Security domain configuration is managed as config.