Skip to main content


Why You Should be Using the Principal Permissions View in AEM

Before AEM 6.5, we really only had one UI to manage user permissions.  That’s not to say we couldn’t go to the JCR directly and set ACLs, but the user admin screen was just simpler.

For instance, take this example from the classic user admin console.

Classic Permissions

Typically, this meant that we would check the root folder to give read to everyone.  This is done because an AEM user can’t do much without access to “/bin” which is directly beneath the root node and you can’t directly add permissions to the bin.

This “read” would trickle down to all of the other nodes.  So, when you wanted to remove access you uncheck the box, you have now added a “deny” policy.

Have you ever accidentally checked a box, saved, then unchecked? You’ve just created another deny. The only solution to remove it is to go and delete the policy.  Even if you delete the user, that deny policy will persist.

Denys not only cause unnecessary clutter, but it also makes troubleshooting permissions issues so much more difficult.  This was a very unclean approach that we adapted to.  Now, we have a better option in AEM to manage permissions.

Touch UI Permissions Console

With the introduction of the Touch UI Permissions Console, you can now set your policies for your Principals.  You also have the option of creating exceptions easily through the UI.

Utilizing the example from before, this is how it looks in the permissions console.

Touchui Permissions

You still have the “read” on root, but now you can create a glob on that node.  Rep:glob=”” sets the read permissions to itself only. This means any nodes directly tied to root will be readable but subfolders will be excluded and will not inherit read.  This gives you more control over what permissions you need to set without having to worry about “accidental” permissions.

I did the same thing on “/content” because authors will get permissions to specific areas through other groups. Again, no need to create a deny.

Although this isn’t a true Principal Authorization implementation, since under the hood it’s still creating the policies for the paths, it’s a big step forward for managing permissions on a more granular level.

Read more about this on the Adobe website.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Diana Henrickson, Senior Solutions Architect

Diana is a Senior Solutions Architect

More from this Author

Follow Us