Roles & Rights and complexity

An important aspect in every project is the roles and rights setup. Typically this runs side-by-side with all other discussions regarding content architecture and content reuse.

While in many projects the roles and rights setup can be implemented quite straight forward, there are cases where it gets complicated. In my experience this most often happens with companies which have a very strong separation of concerns, where a lot of departments with varying levels of access are supposed to have access to AEM. Where users should be able to modify pages, but not subpages; where they are supposed to change text, but not the images on the pages. Translators should be able to change the text, but not the structure. And many things more.

I am quite sure that you can implement everything with the ACL structure of AEM (well, nearly everything), but in complex cases it often comes with a price.

Performance

ACL evaluation can be costly in terms of performance, if a lot of ACLs needs to be checked; and especially if you have globally active wildcard ACLs. As every repository acecss runs through it, it can affect performance.

There is not hard limit in number of allowed ACLs, but whenever you build a complex ACL setup, you should check and validate its impact to the performance.

Wildcard ACLs can be time consuming, thus make them as specific as possible.
The ACL inheritance is likely to affect deep trees with lots of ACL nodes on higher-level nodes.

Maintainability

But the bigger issue is always the maintenance of these permissions. If the setup is not well documented, debugging a case of misguided permissions can be a daunting task, even if the root cause is as simple as someone being the member of the wrong group. Just imagine how hard it is for someone not familiar with the details of AEM permissions if the she needs to debug the situation. Especially if the original creator of this setup is no longer available to answer questions.

Some experiences I made of the last years:

Hiding the complexity of the site and system is good, but limiting the (read) view of a user only to the 10 pages she is supposed to manage is not required, it makes the setup overly complex without providing real value.
Limiting write access: I agree that not everyone should be able to modify every page. But limiting write access only to small parts of a page is often too much, because then the number of ACLs are going to explode.
Trust your users! But implement an approval process, which every activation needs to go through. And use the versions to restore an older version if something went wrong. Instead of locking down each and every individual piece (and then you still need the approval process …)
Educate and train your users! That’s one of the best investments you can make if you give your users all the training and background to make the best of the platform you provide to them. Then you can also avoid to lock down the environment for untrained users which are supposed to use the system.

Thus my advice to everyone who wants (or needs) to implement a complex permission setup: Is this complexity really required? Because this complexity is rarely hidden, but in the end something the project team will always hand-over it to the business.

Why a good business consultant can save you more money than a good AEM architect

In the years working in the consulting business for Adobe I joined many projects. Some only temporary to support on some special issues, others in a broader context; but always it was with a focus on the technology, on implementation, architecture and infrastructure. And with this background, I always tried to help my customers and projects and use the AEM (or CQ5) technology in the right way; to spend their money wisely and cost-effective.

But: according to my own standards I often failed to do so.

Not because I did not know the product. Not because the customer was not listening to me. And not because I was not able to give advice. But because I was not sitting at the right table when some important decisions were made. Because I was sitting with infrastructure teams to build a hardware sizing. I was working with customers architects to understand the constraints under which we have to design and operate AEM. But I did not have enough time to work with the business, understand their needs and the ways they thought AEM can help them. I was not there when they decided on content architecture, components and templates, business processes and how the editors should work. Because my focus is technology, so I talk with the technology people in the first place.

And why is that important for all of us? Because if you don’t know AEM and you don’t have any guidance what it can do and how the existing features can be used, it is very likely that you start building everything on your own. In that case you never use the advanced features of AEM, but you start based on that what you know or what was demo-ed to you by presales people. If you don’t have a person, a trusted advisor, someone knowing AEM very well (and also all the features added to it in the last years!), you start to invest a lot of money to build things which already exist. Too much money.

Let me introduce the AEM business consultant. Someone very familiar with philosophy of AEM. Someone which has an up-to-date knowledge of AEM. Someone which is not a developer, but can map your requirements into AEM features and knows what is possible out-of-the-box and where an existing feature needs an extension on top. And also someone which helps to leverage other features of AEM you paid for.

A business consultant will attend meetings with business stakeholders and with the users which are going to use AEM. A business consultant will help you telling the technologists what they should implement (and what not). And a business consultant is a good partner to the architect and together they can identify the gaps which have to covered by custom development and they frame requirements in a way that they can be covered by out-of-the-box features.

For me often working in an architect role it makes me job much easier if I can focus on the technical aspects. If I know that I have a partner in crime at my side, which makes sure that business users understand the philosophy of AEM; if the business people know what they can get easily; and if they understand what requirement is harder to implement (although it sounds soo easy). Because once an idea has developed in the mind of the business stakeholders, it’s much harder to change it (if that’s necessary). If you as an architect see the requirement before its implementation at all.

Because the worst case scenario is that you are implementing some project features and spend a lot of money on it. And in hindsight it turns out that it could have implemented it with 20% of the time if someone would have told the business and developers, that they just re-invented content fragments (while using AEM 6.3 which has that feature built-in). But because noone told them that, you have designed and built a lot of your application on this custom implementation; and replacing it is expensive. But with a business consultant in the project she would have identified that within the first sessions and helped you to use this out-of-the-box feature.

So a business consultant helps you to spend your money on the right things; and an architect ensures that it is built the right way. Two sides of the same medal.

Do I need a dedicated instance for page preview?

Every now and then there is this question about how to integrate a dedicated preview instance into the typical “author – publish” setup. Some seem to be confused why there is no such instance in the default setups, which allows you to preview content exactly as ob publish, but just not visible yet to the public.

The simple answer to this is: There should be no need to have such a preview instance.

When creating content in AEM, you work in an full WYSIWYG environment, which means that you always should have perfect view of the context your content lives in.Everything should be usable, and even more complex UI interfaces (like single page applications) should allow you to have a proper preview. Even most integrations should work flawlessly. So getting the full picture should alwaysbe possible on authoring itself, and this must not be the reason to introduce a preview publish.

Another reason often brought up in these discussions are approvals. When authors finish their work, they need to get an approval by someone who is not familiar with AEM. The typical workflow is then outlined like “I drop herthe link, she clicks the link, checks the page and then responds with an OK or not. And then I either implement her remarks or activate the page directly”.

The problem here is that this is an informal workflow, which happens on a differnet medium(chat, phone, email) and which is not tracked within AEM. You don’t use the ways which are offered by the product (approval workflows), which leaves you without any audit trail. One could ask the question if you have a valid approval process at all then…

Then there’s the aspect of “Our approvers are not familar and not trained with AEM!”.Well, you don’t have to train them much of AEM. If you have SSO configured and the approvers get email notifications, approving itself is very easy: Click to the link on the inbox, select the item you want to preview, open it, review it and then click approve or reject in the inbox for it. You can definitely explain that workflow in a 5 minute video.

Is there no reason to justify a dedicated preview instance? I won’t argue that there will be never the need for such a preview instance, but in most cases you don’t need it. I am not aware of any right now.

If you think you need a preview instance: Please create a post over at the AEM forum, describe your scenario, ping me and I will try to show you that you can do it easier without it 🙂

Maintenance mode

I just stumbled over my old article on locking out users and felt, that it is a bit outdated. The mechanism described there is only suitable for CQ3 and CQ4, but is not applicable for CQ5, because there is no “post” user, and the complete access control mechanism has changed.

In CQ5 it is incredibly easy to install ServletFilters (thanks OSGI and Declarative Services); so I wrote a small servlet filter, which blocks requests originating from users, which are not whitelisted. That’s a nice solution, which does not require any intrusive operation such as changing ACLs or such. You just need to deploy a tiny little bundle, put “admin” on the whitelist and enable the maintenance in the Felix webconsole. That’s it.

I will submit this package (source code plus compiled bundle) to the Day package share, licensed under Apache 2.0 License. It may take a bit, but I will place it to the public area, so you can grab it and study the source (it’s essentially only the servlet class).

Tip: Lock out the users

From time to time you need to perform maintenance works on your systems; on such highly configurable systems like Communique these tasks can often be performed online while the authors are working. But some task require that there’s no activity on the system; when you want to reorganize your replication agents, it’s a very good feeling when nobody is trying to activate the super-duper important company news. So locking out the users is required.

A very easy method is available, when only superuser should have access. Because the superuser has no ACL, just add a “DENY all” ACL for all users. And the easiest way to do this is to add this ACL to the “post” user. Then the last ACL for every is a DENY to all handles. This effectivly forbids logins, forbids displaying any content for all users but the superuser.

Hints on performance

A lot of things which affect performance can be changed within CQ (without major configuration or even coding just by adjusting the things you want to get displayed or used.

If you’re looking for some performance on your authoring systems, you may consider to disable some information, which is permanently shown to the authors. One of these pieces of information are the number of items in the inbox. This will create every once in a while a background query which slows down your system. It’s essentially the same query which is executed when you open the “Inbox” Tab.

If you’re not using this feature very often, you should disable it for your authors (or at least for the ones who don’t use it).

Open the user settings of the author and un-ceck “Inbox”. If you don’t use notifications, uncheck them too. This will leave you only the link to the impersonation feature which isn’t expensive in terms of rendering perfomancee, but often very useful.