Deny Access to a Folder

Important note when using the walkthroughs

When the walkthroughs refer to some yaml configuration, in general, it is meant that you import this yaml into a locally running repository via the Console with auto-export enabled. If however you copy some yaml blob directly into your idea without auto-export, you have to uncomment the following lines if present in the yaml:

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

The reason for this is that the auto-export for some properties knows implicitly to add this meta info, however the yaml import in the Console does not support .meta lines. Thus, you have two options when following the walkthroughs:

1. Copy the yaml snippet as-is into the Console with auto-export running
2. Copy the yaml snippet to your idea while uncommenting the commented meta info

Introduction

Goal

Deny a group access to a specific folder in the content repository.

Use Case

The use case is based on a Bloomreach Experience Manager project created using the Maven archetype, with the News feature added.

Such a project contains two root content folders:

• /content/documents/myproject
  Contains the news articles.
• /content/documents/administration
  Contains resource bundles to manage static labels on the website.

By default the 'editor' group has editor privileges on both folders, and the 'author' group has author privileges in both folders.

Below is documented how you can

1. Deny the 'author' group all access to /content/documents/administration

2. Optionally grant the  'author' group read-access to /content/documents/administration : this is useful when for example the administration folder contains documents like selection:valuelist which typically are used in pickers when editing a document: You want authors to be able to use these selection list documents when editing a document, so they need read-access selection list documents below administration, but they are not allowed to modify them.

Note

There are multiple ways to achieve the above use case. We'll document below the easiest approach, however per use case detail, you might want to configure it differently. For example, there are also use cases where you rather introduce new groups or even new userroles.

Strategy

To be able to deny access to the administration folder you will customize the Default Authorization Setup as follows:

• Exclude the administration folder from the default content domain at /hippo:configuration/hippo:domains/content.
• Define a new domain hippo:configuration/hippo:domains/content-administration that includes only the administration folder.
• Assign the 'editor/admin' group editor/admin privileges on the content-administration domain.
• Optionally: Give the author group readonly access to content-administration domain

Customize Security Domains

Exclude the Folder from the Default Content Domain

Log in to the Console as 'admin' and make sure that Autoexport is on.

At /hippo:configuration/hippo:domains/content/content-domain add a new facet rule exclude-administration (you can copy paste below and use YAML import on the node content-domain)

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

The above extra facetrule makes sure that the default /hippo:configuration/hippo:domains/content domain does not match /content/documents/administration and descendants any more. This means that not only users with userrole xm.content.author are affected, but also users with userroles

1. xm.content.admin
2. xm.content.editor
3. xm.content.viewer

If we'd only apply the above, also the group editors wouldn't be able to see (read) the /content/documents/administration any more, and the group admin wouldn't have hippo:admin privilege any more (they can read because group admin can read everywhere). Therefore, we need to grant the right privileges again for /content/documents/administration to the userroles above. This can be done a follows:

Create a New Domain for the administation folder

At /hippo:configuration/hippo:domains add a new security domain:

/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 the above changes, validate with the View Permissions Dialog in the Console that an author user doesn't have any permission/privilege on /content/documents/administration while an editor user has the same permissions/privileges as on /content/documents/myproject. 

Optionally: Grant read access to group authors

As explained above, when the /content/documents/administration contains documents like selection:valuelist which are used in pickers when editing documents below  /content/documents/myproject, then most likely the author group still needs read access to /content/documents/administration. This can be easily achieve by realizing that the author group has the userrole xm.content.viewer which can be used to give readonly access. By adding the below configuration to /hippo:configuration/hippo:domains/content-administration, everybody in group author will get read access to /content/documents/administration and descendants:

/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: []

Make sure that after all the above changes everything is synced with auto-export to your local project : doing the above on production involves the risk that on new deployments the changes are overridden since this part of the security domains is config.