Authoring permission restrictions (no publish) | Community
Skip to main content
S
svetlanarezniko
August 2, 2021
Solved

Authoring permission restrictions (no publish)

  • August 2, 2021
  • 3 replies
  • 2037 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Umesh_Thakur

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

3 replies

Umesh_Thakur
Community Advisor
Umesh_ThakurCommunity AdvisorAccepted solution
Community Advisor
August 3, 2021

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
    svetlanareznikoAuthor
    August 3, 2021

    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.

    MarkusBullaAdobe
    Adobe Employee
    MarkusBullaAdobeAdobe Employee
    Adobe Employee
    August 3, 2021

    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!

      joerghoh
      Adobe Employee
      joerghohAdobe Employee
      Adobe Employee
      August 7, 2021

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

        Terms & ConditionsAccessibility statement

        Loading footer...