Authoring permission restrictions (no publish)

The statements are in general correct, but not 100% complete.

Because editing a page also means adding (or removing) components, so the author needs to be able to add and remove nodes within the page. That results in a more complex ruleset, which can be described like this:

* no jcr:write/jcr:create/jcr:remove permissions in /content (ensure that the user cannot create anything)

* provide jcr:write/jcr:create and jcr:remove permissions on the wildcard /jcr:content/* (allow these things to happen below any node named "jcr:content").

Regarding wildcard ACLs I recommend https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html (the search term is "rep:glob"), and deploy it with the Netcentric AC Tool (as recommended by Markus).

Hi @svetlanarezniko!

Yes, there should not be any issue with your requirement.

Please check the available Actions in the context of permissions in AEM. You will find that there are dedicated actions for

• Read
• Modify
• Create
• Delete
• Replicate

and permission management (Read ACL, edit ACL).

So the group that you are outlining would need read and modify permissions but not include create and replicate permissions.

Please keep in mind:

• In general, please only set ACLs on group level and assign users to these groups. It is discouraged (but possible) to set permissions on user level.
• It is recommended to build your authorization concept hierarchical with different groups for different use cases/tenants/markets/etc. and leverage inheritance (one group being member of another) to craft your access controls. In general the top group should have very limited access (potentially deny as much as possible) and subsequent groups in the hierarchy should only have allow ACLs and avoid deny ACLs (as far as possible). Mixing allows and denys on many levels of that hierarchy will make things very complex and debugging very hard.
• I always recommend to leverage the Netcentric ACL tool for group and permission management. This way, you have everything in your SCM and code base and can track changes, deploy them consistently to all your stages and environments and avoid manual errors.

See also the documented Best Practices on permission management in AEM.

You can test your permissions using the impersonation feature of AEM or use the CRX Explorer and it's ACE Editor to prototype and test your permission setups.

Hope that helps!