Enhancements to AEM to support restricted user permissions

[Tim_Goodman_BTE]

Hi,

I get the following requests from clients a lot.

• The ability to have a role which can't edit a page but can annotate for review
• The ability to edit only a section of the page

Is it worth raising these as feature requests?  Is there any workaround now that is commonly used?

Thanks!

[shekhardhiman]

Hi there,

Thanks for reaching out to Adobe Community.

Right now the permissions on a page are available as per the below doc:

https://docs.adobe.com/docs/en/aem/6-0/administer/security/security.html#Actions

However, you can raise that one as a request if you feel the need of such features pretty often.

Thanks!

[Jörg_Hoh · Accepted solution]

Hi,

the annotation thing is "easy" to do, you only need to allow write access to the cq:annotation property, and have read access for everything else. You can do this quite easily using wildcard ACLs [1]. Editing only a section of a page is more tricky, as then this section does always have to have the very same name. Then you can also use wildcard ACLs as well.

The standard (path based) ACLs do not really work here, as the ACL inheritance is not applicable.

kind regards,
Jörg

[1] http://wiki.apache.org/jackrabbit/AccessControl#Principal-based_ACLs, look for the rep:glob property

[Tim_Goodman_BTE]

Thanks - yes often clients ask for more granular access - e.g. access to only edit a single parsys or component on a particular page.  

I think the use case of being able to annotate without edit would be very common

[Tim_Goodman_BTE]

Thanks Jörg

It's good to know that Principle ACLs with wildcards can be utilised to achieve annotation capability, although I'm going to state that these look a bit tricky for a System Administrator to configure in their current state.  

I'm trying to think of the best implementation - Maybe create a script or package that could be run by a Sys Admin.

It would be great if the product could be enhanced to support this as a usable function

Regards,

Tim

[Jörg_Hoh]

Hi,

Well, is setting the ACLs the job of a system admin in your case? I would see it as a developer task to create a content package which contains such aspects :-)

What exactly do you think should be part of the product?

kind regards,
Jörg

[Tim_Goodman_BTE]

Hi Jorg, 

I'm just trying a simple test for this using AEM6.1:

1. Create a new group, which is a member of "Authors"
2. using CRXDE, add  the custom ACL deny write permission, with exception of *cq:annotations

[img]repository permissions.png[/img]

It doesn't seem to work - Was this what you were expecting?

Also, I have noticed that if I try to remove the ACL that I added from CRXDE, I get a 500 error with the associated log message

09.06.2015 16:26:35.065 *ERROR* [qtp1418927216-807] com.day.crx.delite.impl.servlets.ACEServlet Error occur removing acl entry javax.jcr.security.AccessControlException: Cannot remove AccessControlEntry org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl$Entry@270be638 at org.apache.jackrabbit.oak.security.authorization.accesscontrol.ACL.removeAccessControlEntry(ACL.java:79) at org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPrincipalBasedAcl(AccessControlManagerImpl.java:253) at org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:207) at org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.perform(AccessControlManagerDelegator.java:124) at org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.perform(AccessControlManagerDelegator.java:121) at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:216) at org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:121) at org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:151) at com.day.crx.delite.impl.servlets.ACEServlet.removeEntry(ACEServlet.java:430) at com.day.crx.delite.impl.servlets.ACEServlet.doService(ACEServlet.java:104) at com.day.crx.delite.impl.AbstractServlet.service(AbstractServlet.java:52)

Any ideas??

[Jörg_Hoh]

Hi Tim,

I think, that you actually deny the write access to cq:annotations :-) So it should be a allow policy here.

Regarding the stacktrace: Do you have any "caused by" statement in the stacktrace? The code looks like, that there is there is no ACL at all to remove (the ACLs are hold in a ArrayList and the remove() operation on that ArrayList returns "false").

Jörg

[Tim_Goodman_BTE]

OK - thanks.  I couldn't get the permissions to work with either allow or deny, and ordered above or below a matching statement (see image)

Using the Allow - I received errors both times when editing Annotations - e.g. Access denied

[img]ACL Test.png[/img]

Also, I upgraded to the GA version of AEM6.1 (I didn't realise I was using the beta) - and the ordering/deleting issues of ACLs appears to be fixed

Are you able to try it quickly and see if it will work?

Many Thanks,

Tim

[Jörg_Hoh]

Hi Tim

I cannot reproduce your test. I created a user "atest" with a wildcard ACL on *cq:annotations* for the path /content/geometrixx/en/services. And then I added read permissions on / for it. Using the CRXDE I am able to create and update a property "cq:annotations" on /content/geometrixx/en/services/jcr:content.

Jörg

[Tim_Goodman_BTE]

Thanks Jörg

Does that mean that you were able to restrict permissions to allowing edit of annotations only?  Are you able to share the permission list you setup?

Kind Regards,

Tim

[bswx]

Thank you for quick reply. But that's exactly what I tried. 

1) Gave read permission to all pages. 

2) Then added allow policy for the group with rep:glob as /*/cq:annotations/*   

Still I get access denied, also edit is enabled for the all pages. Any specific example would be nice to 

[paul_bjorkstran]

This can be done with normal path-based ACLs, but you need to allow more than just access to cq:annotations.


EDIT: I forgot to mention, the permissions below are on the /content node as allow with jcr:read & rep:write base permissions, and restrictions based on the lists below.

You need to allow write for the following rep:globs

• /*/cq:annotations
• /*/cq:annotations/*

You also need to allow write for the following rep:itemNames

• cq:lastModified
• cq:lastModifiedBy

I also added these rep:itemNames for good measure

• jcr:lastModified
• jcr:lastModifiedBy

The rep:itemNames are needed because when AEM makes annotations updates the cq:lastModified/cq:lastModifiedBy for the page when an annotation is changed (add, modify, delete).

To create them you need crx/de or a similarly powerful tool for ACL management. With crx/de, I have 6 entries for permissions, one for each of the 6 items above.

bswx​ & omallianz, this might be something you are interested in as well.

[omallianz]

paul.bjorkstrand​ thanks, I will check this out.

Update: Thanks paul.bjorkstrand​, checked this and worked well.

Sorry guys, I made some confusion on this. when I checked this last time, I had already given write permission on everything below jcr:content and this worked. However if you just add above 6 acls as mentioned by Paul, it doesn't work. fyi, below is the representation of rep:poilicy node

{

   "jcr:primaryType":"rep:ACL",

   "allow":{

      "jcr:primaryType":"rep:GrantACE",

      "rep:principalName":"annotations-group-example",

      "rep:privileges":[

         "jcr:read"

      ]

   },

   "allow13":{

      "jcr:primaryType":"rep:GrantACE",

      "rep:principalName":"annotations-group-example",

      "rep:privileges":[

         "rep:write"

      ],

      "rep:restrictions":{

         "jcr:primaryType":"rep:Restrictions",

         "rep:glob":"/*/cq:annotations"

      }

   },

   "allow14":{

      "jcr:primaryType":"rep:GrantACE",

      "rep:principalName":"annotations-group-example",

      "rep:privileges":[

         "rep:write"

      ],

      "rep:restrictions":{

         "jcr:primaryType":"rep:Restrictions",

         "rep:glob":"/*/cq:annotations/*"

      }

   },

   "allow15":{

      "jcr:primaryType":"rep:GrantACE",

      "rep:principalName":"annotations-group-example",

      "rep:privileges":[

         "rep:write"

      ],

      "rep:restrictions":{

         "jcr:primaryType":"rep:Restrictions",

         "rep:itemNames":[

            "cq:lastModified"

         ]

      }

   },

   "allow16":{

      "jcr:primaryType":"rep:GrantACE",

      "rep:principalName":"annotations-group-example",

      "rep:privileges":[

         "rep:write"

      ],

      "rep:restrictions":{

         "jcr:primaryType":"rep:Restrictions",

         "rep:itemNames":[

            "cq:lastModifiedBy"

         ]

      }

   },

   "allow17":{

      "jcr:primaryType":"rep:GrantACE",

      "rep:principalName":"annotations-group-example",

      "rep:privileges":[

         "rep:write"

      ],

      "rep:restrictions":{

         "jcr:primaryType":"rep:Restrictions",

         "rep:itemNames":[

            "jcr:lastModified"

         ]

      }

   },

   "allow18":{

      "jcr:primaryType":"rep:GrantACE",

      "rep:principalName":"annotations-group-example",

      "rep:privileges":[

         "rep:write"

      ],

      "rep:restrictions":{

         "jcr:primaryType":"rep:Restrictions",

         "rep:itemNames":[

            "jcr:lastModifiedBy"

         ]

      }

   }

}

As a workaround, we did something like this:

# Allows user to annotate on the pages(wildcard for everything below jcr:content, excluding jcr:content itself) but blocks modifying page properties by restricting access on jcr:content node. See also Jackrabbit Oak – Restriction Management

            - path: /content/we-retail/en

              permission: allow

              privileges: rep:write

              restrictions:

              repGlob: '/*/jcr:content/*'

This will give a permission to create, edit, modify everything below jcr:content(excluding jcr:content).

[padminik5129032]

Hi ,

I have a user with only read permissions and then added all the 6 permissions mentioned above for the user in the crx/de at the /content node.

Now , I am able to edit and update the existing annotation but i am still unable to add a new annotation. Logs show "Access denied".

Is there anything that I am still missing ?

Thanks in advance

[omallianz]

Can you share the screenshots of rep:policy node?

[Jangra98]

Hi Tim/everyone,
Is this functionality got implemented successfully? If yes, can you please share the final solution for this issue! We are also in need to implement the same functionality in our project.