sandstorm/neosacl

There is no license information available for the latest version (2.3.1) of this package.

2.3.1 2024-05-17 10:32 UTC

Requires

• neos/flow: ^7.0 || ^8.0 || dev-master
• neos/fusion-afx: *

Unknown License

README

This package implements dynamic Access Control Lists for Neos Roles.

The development of this package was sponsored by ujamii and queo.

Main features:

• Switch RestrictedEditor to an allowlist-only permission approach. By installing this package, the RestrictedEditor is no longer allowed to change any content.
• Configure dynamic roles through a Neos backend module.
• Permissions on the node tree, workspaces and dimensions possible.
• Permissions work predictably with sane defaults and purely additive logic.

Installation

1. Install the package:

composer require sandstorm/neosacl

1. Run the migrations

./flow doctrine:migrate

1. Log in with an admin account and visit the new menu entry 'Dynamic Roles'

Development

Initial (Package) Setup

• Clone this package as Sandstorm.NeosAcl in the DistributionPackages of a Neos 4.3 or later installation
• Add it to composer.json as "sandstorm/neosacl": "*"
• Run composer update

Initial React Setup

cd Resources/Private/react-acl-editor
yarn
yarn dev

Then, log into the backend of Neos, and visit the module "Dynamic Roles".

Internal Implementation Details

Implementing Dynamic Node Privileges and MethodPrivileges

The basic idea was the following: Hook into PolicyService::emitConfigurationLoaded, and modify the $configuration array (introduce new roles and privilegeTargets). This basically works at runtime - however there is a problem with dynamic MethodPrivilege enforcement, which is explained below and by the following diagram:

How do Method Privileges work

• Background: An implementation of PointcutFilterInterface can - during compile time of Flow - decide which classes and methods match for a certain aspect.
  • This is used in PolicyEnforcementAspect (which is the central point for enforcing MethodPrivileges).
  • There, the MethodPrivilegePointcutFilter is referenced.
  • The MethodPrivilegePointcutFilter asks the PolicyService for all configured MethodPrivileges - and ensures AOP proxies are built for these methods.
• Side Effect: Now, during building up the pointcut filters, the MethodPrivilegePointcutFilter additionally builds up a data structure methodPermissions - which remembers which MethodPrivileges are registered for which method.
  • This data structure is stored persistently in the Flow_Security_Authorization_Privilege_Method cache.
  • At runtime, for a class which is intercepted by PolicyEnforcementAspect, all configured MethodPrivileges are invoked - and they have to quickly decide if they match this particular call-site.
  • This is done using the methodPermissions data structure from the Flow_Security_Authorization_Privilege_Method cache.

What's the problem with dynamically added MethodPrivileges

• If a MethodPrivilege is defined dynamically at runtime, then the methodPermissions data structure is missing the information that this new privilege should be invoked for certain methods.
• NOTE: You can only dynamically add MethodPrivileges for call-sites which are already instrumented by AOP; because otherwise the code will never get invoked (because of missing proxies).

We are mostly working with EditNodePrivilege etc. - so why does this apply there?

• EditNodePrivilege has an internal MethodPrivilege which takes care of the method call enforcement part; i.e. preventing you to call e.g. NodeInterface::setProperty() if you do not have the permission to do so.

Furthermore, to make this idea work, the Policy.yaml of this package defines a catch-all Sandstorm.NeosAcl:EditAllNodes PrivilegeTarget - so AOP will instrument the corresponding methods of NodeInterface. This catch-all makes sense in any case, because this switches the security framework to an allowlist-only approach

• making it easier to grasp.

The goal

In order to make the dynamic policy enforcement work, we need to add custom stuff to the methodPermissions - for the dynamically added roles.

Implementation

The post-processing of the methodPermissions is done using a custom cache frontend (SecurityAuthorizationPrivilegeMethodCacheFrontend).

Implementing dynamic AOP Runtime Expressions

Method privileges internally can use dynamic AOP Runtime Expressions (in case you check for method parameters). Especially the MethodPrivilege - which is attached to the RemoveNodePrivilege - uses the following expression code:

return 'within(' . NodeInterface::class . ') && method(.*->setRemoved(removed == true))';

The removed == true part is a so-called AOP Runtime Expression.

This is internally implemented using the Flow_Aop_RuntimeExpressions "cache", which is pre-filled again during the compile time (which is a nasty side-effect).

Thus, in our case we need to again implement a custom cache frontend (AopRuntimeExpressionsCacheFrontend), using the runtime expressions of the base configuration, which exists properly.