Configuring AEM User Permissions and Access

I remember the first user permission story I had to complete — Design and Implement User Permission Matrix. My task, in a nutshell, was to create user groups, organize user groups, assign permissions as well as create users. It sounded straight forward until I started work and found myself spending way more time than I expected myself to take.

Two Different Interfaces To Configure User Permissions
There’s the Classic UI View and the Touch UI View. The latter was only introduced in late 2019.

Classic UI Permissions View

I initially chose to work on Classic UI because I would not have to go into three separate pages, unlike the Touch UI view:

For Classic UI, you just have to go into

• localhost:4502/useradmin

For Touch UI, you would have to go into

• localhost:4502/security/users.html
• localhost:4502/security/groups.html
• localhost:4502/security/permissions.html

I created user groups and users successfully, hooray! Permissions were in a mess though, as it turns out. The reason was…

Seemingly Harmless Unchecks on Classic UI

Classic UI Permissions Granting

You would think that if contributors do not have to access templates which are under the path, conf/templates, you just have to uncheck that box. What that does, in reality, is to create an explicit deny.

And what’s wrong with explicit deny, you may ask.

Explicit Denies Will Be Inherited When Assigning a User to Multiple Roles
If this specific user is part of the Contributors Group which has conf/templates denied and also part of Template Editors Group which has conf/templates checked, he/she will end up not being able to access conf/templates due to that explicit deny.

Then, what to do right?

Use Principal Permissions View on Touch UI and Get This Counterintuitive Rule in Your Head
Just do not explicitly allow a path if you do not want it to be allowed — eg. if I never explicitly allow /conf/templates for contributors, AEM will assume that it is not allowed and achieve a “deny” effect without an explicit deny.

That way, if this specific user is part of the Contributors Group which has conf/templates implicitly denied, and also part of Template Editors Group which has conf/templates allowed, this user will be able to achieve the highest level of permissions among the user groups he/she is assigned to, as expected.

There May Be Some Cases Where You Need Explicit Denies. Don’t Forget About The Explicit Allows
There may be cases you need to apply some restrictions to some supergroup (etc. Pizza Company Non-Admin Super User Group) which has many user groups. You would need to ensure that the alternative user group (etc. Pizza Company Admin Super User Group) has explicit allows for overriding purposes.

Thereafter, if a user is part of a non-admin sub-group as well as an admin sub-group, this user will not be affected by the explicit denies due to the explicit allows and be able to achieve the highest level of permissions among the user groups he/she is assigned to, as expected.

You Would Also Need Absolute Path (Or Substring of Absolute Path) to Allow/Block The Path, Yet There Are URLs That Cannot Be Found

Sample Detailed Look at ACL with its Paths Defined

File Navigator When Configuring User Permissions

There are some pages that are the likes of localhost:4502/communities/sites but you would realize from the file navigator that the path does not exist. That means that it is a vanity URL and not an actual path.

To find its actual path, go to localhost:4502/system/console/jcrresolver and then copy and paste the vanity path — you will then be able to find the actual path. For the case of the communities, they are found under the path localhost:4502/libs/social/xxx.

JCR Resolver View

As you can see, this new path you got from the JCR Resolver does exist in the file navigator. We can then proceed with our allows/denies.

I Literally Had A Nightmare Each Time I Work on User Permissions
Coding over configurations, anytime. At least I don’t have to go “Why is it designed like that”.

It also does not help that there are so few conversations about AEM User Permissions and Access — that is also one of the strongest reasons why I have decided to write about this.