Security

Neos 9

This page is for Neos 9.0 with the new Event Sourced Content Repository.

#Workspace Permissions

VIEWER: Can read from the workspace
- By default, everybody is a VIEWER to the live workspace
COLLABORATOR: Can read from and write to the workspace
MANAGER: Can read from and write to the workspace and manage it (i.e. change metadata & role assignments)

Furthermore, personal workspaces can be owned by a particular user. The workspace owner implicitly has the MANAGER role, i.e. has full access to that workspace.

Workspace roles are transitive. That means that COLLABORATORhas all privileges of the VIEWER and MANAGER has all privileges of the COLLABORATOR

To publish changes to a workspace, the authenticated user has to have at least the VIEWER role on the workspace to publish and COLLABORATOR role on the target workspace.

Workspace role assignments will be changeable with the new workspace module or via CLI:

./flow workspace:assignrole

#ReadNodePrivilege

In general, the ReadNodePrivilege works like it did before Neos 9: It allows to completely hide sub trees of the content repository from a given user group.
But the implementation and configuration format has changed.

This is how a ReadNodePrivilege can be configured via Policy.yaml:

privilegeTargets:
  'Neos\Neos\Security\Authorization\Privilege\ReadNodePrivilege':
    'Neos.Demo:ReadBlog':
      matcher: 'blog'

The matcher refers to a SubtreeTag, so this example would hide all nodes that are tagged with blog (including their descendants) from all users that don’t have a GRANT on that specific privilege target.

By default, the privilege is active for all configured content repositories. By prefixing the matcher with <content-repository-id>: this can be limited to a specific CR (for example default:blog)

#EditNodePrivilege

Likewise the purpose of the EditNodePrivilege is like before Neos 9: To restrict certain users from changing nodes (includes creation, setting properties or references, disabling/enabling, tagging and moving, …) in a given subtree.

The new configuration syntax is similar to the one for ReadNodePrivilege:

privilegeTargets:
  'Neos\Neos\Security\Authorization\Privilege\EditNodePrivilege':
    'Neos.Demo:EditBlogNodes':
      matcher: 'blog'

Again, the matcher refers to a SubtreeTag, so this example would disallow users without a corresponding GRANT permission to edit nodes in the subtree that is tagged blog.

Both privileges expect a subtree to be tagged. That is not yet possible via the Neos UI or CLI but requires interaction with the PHP API ($contentRepository->handle(TagSubtree::create(....)))

#Removed privilege types

The following Content Repository privilege types have been removed because their behavior was inconsistent and/or because they led to (performance) issues: NodeTreePrivilege, CreateNodePrivilege, ReadNodePropertyPrivilege, EditNodePropertyPrivilege

We will most probably re-add some of the functionality in a future version, but for now you can implement the AuthProviderInterfacein order to enforce custom authorization requirements.

#Examples

#Disallow a role to edit nodes of a subtree

With the following Policy.yaml:

privilegeTargets:
  'Neos\Neos\Security\Authorization\Privilege\EditNodePrivilege':
    'Neos.Demo:EditBlogNodes':
      matcher: 'blog'
roles:
  'Neos.Neos:Administrator':
    privileges:
      -
        privilegeTarget: 'Neos.Demo:EditBlogNodes'
        permission: GRANT

only administrators are allowed to edit nodes in the blog subtree.

The Neos UI does not currently properly reflect readonly nodes – The inspector will be empty and inline editable fields will be editable – but changing their content will lead to an AccessDenied exception

In order to also hide the uneditable subtree, the following can be added:

privilegeTargets:
  # ...
  'Neos\Neos\Security\Authorization\Privilege\ReadNodePrivilege':
    'Neos.Demo:ReadBlogNodes':
      matcher: 'blog'
roles:
  'Neos.Neos:Administrator':
    privileges:
      # ...
      -
        privilegeTarget: 'Neos.Demo:ReadBlogNodes'
        permission: GRANT

#Allow a role to only edit within a given subtree

To achieve the opposite of the above, granting a user group to only edit nodes within a subtree, the whole tree must be tagged (i.e. the homepage node, all descendants will inherit the tag).

With all nodes being tagged demosite and the blog nodes beeing tagged blog in addition, the following Policy.yaml will do:

privilegeTargets:
  'Neos\Neos\Security\Authorization\Privilege\EditNodePrivilege':
    'Neos.Demo:EditAnyNode':
      matcher: 'demosite'
    'Neos.Demo:EditBlogNodes':
      matcher: 'blog'
roles:
  'Neos.Neos:Administrator':
    privileges:
      -
        privilegeTarget: 'Neos.Demo:EditAnyNode'
        permission: GRANT
  'Neos.Neos:Editor':
    privileges:
      -
        privilegeTarget: 'Neos.Demo:EditBlogNodes'
        permission: GRANT

With that, the administrator will be able to edit any node, but editors can only edit nodes within the blog subtree.