There is a caveat that we need to point out to this architecture and that is the process in which you create these groups. The order in which you create your (deny and allow) permissions do matter. If it is done incorrectly, then a user who belongs to both groups will not be able to access the content they need to. One of the reasons for this is the nature in which ACLs work. An ACL policy observes the last rule that matches in the list.
This is one of the indications that something is configured incorrectly. Allow me to illustrate with an example. I have two groups: aemoutdoor and aemgov. I also have an aemproject group. Their permissions are set according to what our past article outlines. Aemproject has denied access to geometrixx-gov and geometrixx-outdoor. And the other groups I have created read permissions to their respective content. See below:
I then added these groups to the aemproject deny group; however, something is amiss that we can’t tell yet.
When I create a user name bob and try to add him to the aemgov group and the aemoutdoor group he can’t see anything from the gov site and the outdoor site. What happened!? This is the caveat I forgot to mention in my article. If we go to geometrixx-outdoors content and take a look at the re:policy node we will see that the node has 3 nodes. The LAST node is a deny policy with all allows above it. Since bob inherits the aemproject group from aemoutdoor group, this policy will apply since it’s the LAST matching policy.
ACL works a lot like the dispatcher filter rules if you have any familiarity with them. How do you diagnose and remedy this problem? The best way is to look at the useradmin. I STRONGLY discourage editing policies inside of crx since things can go amiss very fast. We can see this problem in the user admin by looking for those pesky exclamation marks. If you remember Adobes documentation the exclamation marks denote that there are noneffective permissions being overlaid by a policy. In this case, we can see that the aemoutdoor policy is ineffective because of the deny that we have in the aemproject group.
To remedy this issue, we simply just need to check the read box for this AEM Outdoor Group so that anyone belonging to this group can read this content. The AEM Outdoor Group should look like this now:
Long story short, the order in which you create these permissions matter a great deal. The above example was made to show that if you create these deny permissions AFTER you create the allow permissions, then you will face this insidious bug. This is why Adobe cautions people against using deny permissions frivolously. The order in which you create allow and deny policies matter a GREAT deal.
One way to validate that these permissions are configured properly is to look for exclamation marks in the useradmin. You can also check your nodes in crx to see if the deny policy is NOT the last policy in the list under the rep:policy node. If the deny policy that belongs to your deny group is LAST, simply open up the gate from the group by editing that allow permission in the useradmin.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.