Setting Permissions For A Smooth AEM Authoring Experience

Adobe Experience Manager allows for multiple websites to be hosted on the same instance. Multiple teams that have unique projects can manage their content on one platform. If you want to segregate content so that one team does not see content from another team, the right permissions need to be set. I was the developer responsible for making sure that these permissions were set up initially for various groups on a AEM instance. The intention for this was to ensure that all workflow processes were set up correctly for each team that was on the same Adobe Experience Manager environment.

This was the issue that we were facing in detail:
We needed to allow for users that were part of different teams to access the same Adobe Experience Manager instance. These users consisted of authors, editors, approvers, and others with different permissions based on various business rules within their teams. For example, one team would only have authors and editors that would manage all of their web content. Another team using the same AEM environment would have authors, editors, content approvers, intellectual property approvers, and other groups associated with their web content.

The conundrum we faced was that we did not want content from one team showing up in another team’s authoring experience. We found paths where content from one project could potentially overlap another project. We will refer to these paths as contact points. We found contact points in the following paths:

  1. /content/*
  2. /content/dam/*
  3. /etc/tags/*
  4. /etc/clientlibs/*
  5. /etc/designs/*

One could solve this by simply denying all the content that does not correspond to the project with which the group is associated.

An example of this would be to create a few groups named AEMWorld, AEMOutdoors, and AEMGov. The AEMWorld team project would have a AEMWorld Author group. This group would be created with read access to everything in the AEMWorld project, but would be denied read access to every other AEM project on the AEM instance at a contact point. So if we had AEMOutdoors and AEMGov projects on the same Adobe Experience Manager instance, then the AEMWorld Author group permissions may look like the following:vaugnerarticle-image01

This should give you an idea of what the AEMWorld Author group should look like. You would set up their permissions so that content from other projects would not show up in their authoring experience. You would also give them additional permissions to content that they would be responsible for. The same pattern would then be repeated for each project-specific group on the AEM instance.

This solution works well if you only have a few projects on the same Adobe Experience Manager instance and there are not too many projects to be concerned with. If you plan to have a large number of projects on the same AEM instance, then the management of permissions for every group will grow exponentially. Each time a new project is deployed to the instance, an administrator will have to go through every group and at every contact point deny the new content that was introduced to the AEM instance.

This could lead to a lot of overhead effort that could potentially become impossible to maintain. Like I mentioned before, if there are only a few projects and you feel that you can manage all of this work, then it may be a feasible solution; however there is one other potential problem you need to take into consideration.

In Adobe Experience Manager, there is an insidious bug that Adobe warns about in their documentation concerning setting denial permissions. This bug will express itself if the first approach is taken to this problem. If the expectation is held that one user can belong to multiple groups across projects, then setting permissions on individual groups as proposed above will fail.

One solution that I discovered was to do the following. Create a group that every other group would belong to. This group would deny access to all content where content has the potential of overlapping. I called this a contact point, since it is a location where content from various team projects has to be and has contact with other content. The key to making this all work is to have every group inherit from this parent group.

The foundation for this solution is to utilize the hierarchy capability of permissions. We would introduce a group called aemprojectgroups. This group would be responsible for denying content at the specified contact points. It would have high-level read access necessary for a user to be able to access the authoring environment of AEM, but would deny access to all child content at a contact point. You can almost imagine it acting like a gatekeeper.

So aemprojectgroups would look like the following:vaugnerarticle-image02

and then an AEMWorld Author group would look like the following:vaugnerarticle-image03

The AEMWorld Author would automatically be blocked from all other project content because it inherits the denied read access to everything else. They would also be allowed to see the content that they are interested in because it has been marked as allowed for their group. The elegant part comes from the maintenance of this system. If another project needs to be introduced into the AEM instance, then an administrator just needs to set the denial permissions to the aemprojectgroups of all the new projects’ content. Then they would simply create new groups that inherit from aemprojectgroups and set the allowed permissions necessary.

Here is a chart of the general idea:Permissions1

The solution is essentially to create a hierarchy of groups with the highest parent being the denial gatekeeper.

No user would ever be assigned to the aemprojectgroups group, since that would deny them access to all content. If you refer to the chart at the top, then you could say that you would only assign users to groups in the colored areas. The main functional purpose of the aemprojectgroups group is to mitigate the amount of denial permissions you have to set and make denial permissions manageable. It also allows the system to be scaled linearly as opposed to exponentially.

You could take this a step further and create another layer of groups that would make managing multiple groups in each team project easier. The visual would look like the following:Permissions2

Doing this would eliminate the extra read permission that you would have to set for each group. Like mentioned above, no specific user would belong to the parent groups. A user would only be assigned to a group that inherits from one of the three AEM groups. This may look like overkill, but if you have many groups to maintain, it get laborious setting read access for 20 groups in a single project on an AEM instance. This was the case in the project that I had to manage.

Another elegant fix that this solution provides is the capability for one user to act in multiple roles. One user could be assigned to the AEM World Author group and the AEM Outdoors Author group without any complications. Doing this would give them visibility to both projects when they logged into AEM. Using this hierarchy user/group solution eliminates the potential for the denial bug to express itself that Adobe warns about in their documentation. This may be a consideration for you if you have users on your Adobe Experience Manager instance that play multiple roles in multiple team projects.

Permissions are key to facilitating a smooth authoring experience in AEM. It is possible to set up the correct permissions for any user in AEM so that their experience is smooth; however, you will want to create a scheme if you plan to have multiple portals on the same AEM instance. Having a elegant permission scheme will help make maintaining permissions easier and simplify many potentially complicated scenarios. Learning to share the same AEM instance is important and having the right permissions set up can make that sharing experience possible. Feel free to reach out to us with any specific questions about permissions within AEM to our email: