Authoring permission restrictions (no publish)

[s-reznikov]

Hi, the question is: is it achievable to create a permission for a user to be able to

-edit existing pages,

-but not to create new pages and

-not to publish? 

Thank you.

[Umesh_Thakur · Accepted solution]

Yes it is pretty much doable:

in http://localhost:4502/useradmin you can provide read and modify access to /content node then your project node to the specific user thats it.

NOTE: if you provide read permission to /content node then, this permission will be available on all the child nodes by default so if you don't want, you can manually remove that permission from the child nodes.

Hope this will help.

Umesh Thakur

[s-reznikov]

Hi, thank you for your response! 

I am aware of useradmin (AEM / Security). But would granting user permission on a folder prevent from 1) creating new pages under that folder and 2) publishing pages you have access to.

I understand, that if you grant permissions to individual pages, this user will be able to edit the pages. But how to prevent publishing?

Thanks again.

[Umesh_Thakur]

You have one Replicate option on the user admin page if don't enable that checkbox it means you are not giving permission to that user to replicate any or some certain content.

So in your case you can provide read and modify permission but deny Replicate permission of folder or on certain page.

Hope this will help now.

Umesh Thakur

[kautuk_sahni]

@Umesh_Thakur, good to have AEM SMEs like you back in the AEM community. Looking forward to see you more.

[markus_bulla_adobe]

Hi @s-reznikov!

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!

[Jörg_Hoh]

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