Best means of providing granular page or field level security/access in AEM

Thanks Jorg!

Jörg Hoh wrote...

Hi,

To 1) and 2): Try to avoid to put access control down to a page level; it is possible and there are usecases for it, but doing so gives makes you a lot of work to define, implement and maintain it. It is constant work! And while technically you can even implement access control down to a property level: Don't do it.

To 3): The term "ACL" in the AEM world is the only existing one; even other products might have different approaches and implementations, ACLs as a list of ACEs is the only implementation.

ACLs are defined within the content and are not assigned and stored with the principal; so LDAP can be a very good choice as protocol to connect to an external IDP, but it doesn't allow you to define ACLs.

Jörg

 

Jorg, can you or someone else give a couple of examples as to the constant work that would be required for page level access? What type of events, changes trigger work? E.g., for page level access, you'd have to do it for every new page? Is that what you're referring to? Please give additional examples, (especially real life), if you have them.

If you really do need page level access control, is there a better way than implementing ACL's on a page? What is the best practice for use-cases where that level of security is really required.

Hi,

if you want to use ACLs per page as general solution for your usecase, you'll run into problems.

• First of all, whenever someone creates a page, you need either to give that author the permission to create a page at the desired or specified location. Or you need to adjust the permissions to the page after it has been created. Is this doable from your authoring process? Is a regular author able to work with that? How does this affect your time-to-market and the user experience for the authors? I assume, that this process of assigning new ACLs can hardly be automated.
• Changing ACLs based on repository activities:  I would not recommend that. Imagine a case, when someone not aware of familiar with this approach creates a page and magically it changes permissions, so he's no longer able to perform changes on that page. Also you need to hardcode the ruleset in a way.
• In the end: An easy permission model is easier to teach and understand than a complex model. Understand that in the end the complexity of operations also influences the acceptance of your solution. Don't make your system hard to change and hard to extend because of its permissive access control.

I don't have good real life examples for complex permission systems, because I always tell customers to avoid them. Implement what's necessary and make sure that your content structure supports your permission structure. Then you can often have the case, that after the initial setup of permissions no adjustments to them are required for quite some time, until requirements change.

So can you elaborate on your usecase? I would like to understand the details and the reason why you think that page-level ACLs are the best solution for it.

Cheers,
Jörg