!!! FEATURE: Content Repository Privileges

[bwaidelich]

Introduces basic security to the event sourced content repository

This is a breaking change mainly because it requires a new, explicit, workspace role assignment in order for the live workspace to be publicly visible:

./flow workspace:assignrole live "Neos.Flow:Everybody" viewer

Otherwise youll face this error:

Read access denied for workspace "live": User is no Neos Administrator and has no explicit role for workspace "live"

Adjustments to VisibilityConstraints:

The method VisibilityConstraints::frontend() was renamed to VisibilityConstraints::default().
But for the cases you have used VisibilityConstraints at all - as mandatory argument for getSubgraph you can now simplify that to use getContentSubgraph directly:

before

$subgraph = $contentRepository->getContentGraph($nodeAddress->workspaceName)->getSubgraph(
    $nodeAddress->dimensionSpacePoint,
    $nodeAddress->workspaceName->isLive() ? VisibilityConstraints::frontend() : VisibilityConstraints::withoutRestrictions()
);

after

$subgraph = $contentRepository->getContentSubgraph($nodeAddress->workspaceName, $nodeAddress->dimensionSpacePoint);

Note that getContentGraph(...)->getSubgraph(...) still works but is only meant to be used if your you want to determine the VisibilityConstraints for some case differently.

Usage

Workspace Permissions

The following workspace roles exist:

• 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.

Note

Workspace roles are transitive. That means that COLLABORATOR has 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 can be changed through the workspace module (WIP, see #5132) 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.

Tip

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.

Note

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(....))) – we'll provide a way to do that, follow #3732 for updates

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 AuthProviderInterface in 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.

Note

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.

Related: #3732

[mhsdesign]

Feels already a lot better with the WorkspaceService being split up and the new $roles, $userId signature in the authorisation service. Now everything is sound :) Left a few last comments and solved the nitpicks myself. After addressing those i think this can be merged finally! Thanks for sticking to this topic so long!!!

I also tested that the Neos ui still works (e2e ran locally) and adjusted it to the latest changes.

One more thing though, maybe @kitsunet wants to have a look at the things that are evaluated often and might need to be cached? See \Neos\Neos\Security\Authorization\ContentRepositoryAuthorizationService::getVisibilityConstraints? And the write side now has to fetch the node again and its workspace but i guess that is ok though could be cached too at some point ... idk :D

But giving my +1 already because of goodwill :D

[mhsdesign]

should we throw the flow access denied here or the CR's \Neos\ContentRepository\Core\Feature\Security\Exception\AccessDenied like in the other methods? Probably the latter?

[mhsdesign]

the more i think about it, yes, otherwise some methods would throw the one and others another :D

[mhsdesign]

now that we can make things @internal by not exposing it here on the workspace service we can consider if getWorkspaceRoleAssignments should really be API or if Neos can just use at this one place the metadataAndRoleRepository directly? ... But probably keep it api :D

[mhsdesign]

Why am i thinking about this? Because the

NOTE: This should never be used to evaluate permissions, instead {@see ContentRepositoryAuthorizationService::getWorkspacePermissions()} should be used!

Makes it already seem like an internal thing somehow :D

[mhsdesign]

do we need some flow error option or anything so this is treated as flow AccessDeniedException in the parts that matter? Or does it matter at all? I do know we have some special condition sometimes to let AccessDeniedException always bubble up or something: (at least in the fusion runtime)?

[mhsdesign]

With the new nullability i could actually imagine to just ignore that check here and use $currentUser?->getId() like in other places ... that makes the code imo less quirky as the security part in flow is defined via yaml and not in the code.

But will do that inside of sebs workspace pr instead of messing with the workspace controller to much :D

[mhsdesign]

i didnt add tests yet for these things that they work with security will try to do that in your followup pr :) For now its just withoutAuthorizationChecks :D

[mhsdesign]

is this latter part really needed? As we dont have sub processes we dont have to preserve the state and mess with the file system right?

... but ill look into it :)

[bwaidelich]

Without that I got more failing tests because we have so many runtime caches on all layers

... but ill look into it :)

Great, thank you. And let me know if you need support (contentually or mentally *g)