Managing user access on the baseline content architecture of your AEM assets implementation is often a critical aspect of governance and insurance business process can be properly supported. Managing permissions on the baseline folder structure isn’t formed by both the content architecture and the governance and processes that guide the use of the AEM. To understand how permissions are applied in AEM assets, let’s jump over to the whiteboard.

Here, we’ll walk through the various concepts and the relationships that are used to grant a user, some level of access to an assets folder. First, we start off by creating a user group that represents the role we want to model permissions and access for. Multiple user groups may end up having overlapping permissions. Once we have a list of AEM user groups, we need to think about what their purpose is in AEM. We may have creatives that contribute assets, marketers that curate and manage the approval and use of assets and legal who only needs to review assets, but never update or change them. Once we have our custom groups and an understanding of what they need to do, we need to review the AEM provided user groups and determine if we can leverage any of them to provide baseline levels of access. Custom user groups should almost always leverage some AEM provided user group. For example, the out of the box contributors group, which provides a baseline level of read access in AEM author, effectively allows users to log into AEM and navigate the content in a mostly read only fashion.

AMS has users that need to create, modify or delete assets can leverage the DAM Users group and users that need to engage with AEM’s workflow, for things like review and approval can leverage the out of the box workflow users group. So what we’ll want to do is make our new custom user group, a member of one or more of the AEM provided user groups, allowing it to inherit any permissions assigned to those out of the box user groups. This is a great and easy way to ensure your users will have access to the basic UIs and functionality in AEM Author. It has the added benefit of when new features are added to AEM that require permissions to use them, these AEM provided user groups will be automatically assigned the necessary permissions by the product team. Okay, so now we have a grasp on what we need to do with regards to user groups. In short, create custom user groups and figure out what AEM provided user groups they should inherit from. Next, we have to look at our assets, content architecture, and understand what permissions each user group needs for the various folder hierarchies in AEM. So, creatives may need read and write access to the Dropbox folder. Marketers may need read and write access to everything and legal only needs read access to everything and should not be allowed to write or make changes. AEM manages the permissions a group has for a folder through access control lists or ACLs. These are basically a list of entries that read group X has Y permissions on folder Z. For instance, we can define an ACL entry or ACE that defines creative user groups have read and write permissions on content DAM Dropbox, looping back around to AEM provided user groups. If we inherit from these, we also inherit all the permissions provided by their access control entries. For example, the AEM provided DAM users group has read and write permissions on the root DAM folder and everything below, along with a variety of other access control entries that allow its members to interact and see elements of AEM like metadata, schemas, collections, core navigation, elements, et cetera. Similarly, the out of the box workflow users group provides permissions that allow its members to interact and use AEM workflow. Making a custom user group a member of the out of the box groups allows us to easily and transparently inherit all the permissions provided by AEM and then if needed, layer on our own permissions on top. Okay, so now we have our user groups layered up the access control lists to provide specific permissions to selected folders. The last thing we need to do is extend this access to a user since users are who log in day yet to do work. This is super simple. All we need to do is add the user in AEM to the new custom user group. And they inherit all the permissions granted to that user group. Alright, so that was a lot to keep straight. Let’s run through it again quickly, using a scenario where we want to have an AEM user named David have that user be a member of a custom creatives user group that has read and write access to our AEM asset’s Dropbox folder, as well as leverage AEM workflow, So they can engage with marketers and the asset review process. However, we don’t want creatives to have write access to any other asset folders. First, we’ll create a custom creatives group. Then we’ll make this group a member of DAM users, which provides read and write access across the DAM, as well as the workflow users, which will provide access for the user to engage with workflow. Then we’ll identify the folders we need to adjust permissions on. In this case, we need to ensure this group only has read access to assets unless they’re in content DAM Dropbox, and then they need read and write access. Remember that DAM user provides write access to all of AEM assets at the content DAM level. So, we’ll need to override that write permission. Then we need to create our access control list, which will be as follows. Creative users should be allowed to read access to the root assets folder at slash content DAM. And remember, this is provided by the DAM users group already.

Creative users should be denied write access to the root SS folder at slash content DAM and everything below, and creative users should be allowed both read and write access to slash content DAM Dropbox. So it will create two ACLs, one for slash content DAM that denies write access and one for slash content DAM Dropbox, which allows write access. Keep in mind, the read access is provided by the out of the box DAM users group at the slash content DAM level. Once the ACLs are defined, then the user group is ready for use. We can add our AEM user to the creatives group and they’re ready to start using AEM. Okay, let’s jump back to AEM and actually set this creative users group up.

We’ll start by going to tools, security groups and creating a new group for our creatives.

Next, we’ll add this group as a member of the AEM provided DAM users and workflow users group. So, we’ll jump back to the groups listing and open the DAM users’ group. And we’ll add our new creative group as a member of this group.

We can see here, the DAM user is already a member of workflow users. So, we can simply use our membership in DAM users to also inherit the permissions of workflow users. Now that we have our group defined and our baseline permissions inherited from the DAM users and workflow users groups, we’ll head over to tools, security permissions. We’ll search for our new creative group and select it.

The right panel displays all the access control lists and entries assigned to this group. Note that this will not show inherited permissions. So, we won’t see the permissions provided by the DAM users or workflow users groups provided through inheritance. To see inherited ACLs and ACEs, we must look up those groups directly and this will display their permissions applied throughout AEM. So, as you can see, DAM user prides quite a bit of access. So it’s really nice to reuse this group rather than trying to reinvent the wheel and apply all of these yourself to the custom creatives group. Let’s jump back to our creatives group and we’ll add our two access control entries or ACEs. The first will be to deny write access on slash content DAM. Since the inherited DAM users group automatically provides write access to this. First, we specify the path in AEM to permission, which is slash content DAM. Then we pick the privileges we’re interested in allowing or denying. And since we want to deny write access we’ll select rep colon write, note that there is a high level of granularity and privileges. So, make sure to read up on them in the docs before applying them haphazardly. Then select deny or allow based on if we want to deny or allow the select privileges. In this case, we want to deny write access so I’ll tap deny. And restrictions allow for even more advanced application of privileges that we won’t get into here, but you can do things like apply privileges to specific properties or on paths that match a specific pattern or even a specific node type. Needless to say, you can do some pretty advanced and complex permissioning, but we’ll keep our use case simple and just save this entry. Now that we’ve denied all rights to the creatives group on the route asset folder, we’ll want another ACE that allows our creatives to write to assets in the Dropbox folder.

So, we’ll specify that path.

We’ll select the rep right privilege and note that this is the same privilege that we denied at the root level. And we’ll select allow since we want to allow rights to this folder and we just add the ACE.

So, we’re almost done. The last thing we need to do is at our user to our new creatives group. For this, we’ll hit back to tools, security groups, open our creatives user group and add our user as member.

And now we’re ready to try it out. Since I’ve logged in as administrator to make all these changes, I also have the ability to impersonate our creative user. So, let’s do that.

So now I’m logged in as a user that’s part of the creative group and we’ll navigate to assets and we can see that we still have all the normal tools available like collections and shared links. We’ll jump into files and notice there’s no create button at the root level. So, we can’t create folders or new assets here. Likewise, if we drill down further, we still don’t have the ability to create anything.

And if we select an existing asset, none of the modifying operations like edit or move are available since we don’t have write access. Also opening the properties for an asset. Metadata is in a read only mode.

So, let’s head over to our Dropbox folder. Since this is the only folder we should be able to create an edit assets in, and sure enough, we can create folders and upload assets here.

Selecting assets. We have all the usual controls that allows for modifications of the asset.

And opening the properties, we can also edit the metadata.

Okay. I hope this helped you understand how baseline permissions can be defined and applied in AEM. -