Why You Should be Using the Principal Permissions View in AEM | AEM Community Blog Seeding

[kautuk_sahni]

Why You Should be Using the Principal Permissions View in AEM by Perficient

Abstract

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.

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.

Read Full Blog

Why You Should be Using the Principal Permissions View in AEM

Q&A

Please use this thread to ask the related questions.