Enhancements to AEM to support restricted user permissions

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!

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

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

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

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??

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

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

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

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