AEM Access Control With RepoInit: Groups, Permissions, and Practical Patterns

Juan Ayala
4 minutes ago
5 min read

Every AEM project reaches a point where permissions need to be set up. You can’t let every user create, change, or publish content whenever they want. You need clear job roles like authors, reviewers, publishers, and administrators.

AEM as a Cloud Service uses IMS for identity. AEM on-prem may use LDAP, SAML, or local accounts. The identity source may change, but one thing stays the same. You still need to map these job roles to access control rules.

I rely on RepoInit scripts to create groups and apply permissions in a repeatable way. RepoInit is a version-controlled method for defining groups and ACLs through code. As opposed to clicking around the UI to rebuild permissions in every environment.

This post walks through a simple, fictional example. On how to design groups and create them using RepoInit. It’s not a final standard. But a practical pattern you can adapt to your own project.

Planning the Access Model

Before writing any RepoInit, you’ll want to sit down with your stakeholders. To map out the roles and responsibilities needed for the project. This is where you define the project’s Role-Based Access Control (RBAC) model.

In simple terms, this means identifying job functions. Like authors, reviewers, publishers, and administrators. For each role, you decide what actions they can perform. And which parts of the content tree they can access.

Because I can’t share a real client setup, the rest of this post uses a fictional example.

A Fictional Example

I wish I could give you a real world example. But you know, client confidentiality and all. Plus, every time I've had to design an RBAC model, clients bring different requirements. So, to keep things clean, let’s imagine a fictional organization with two separate sites:

Site A: /content/site-a
Site B: /content/site-b

They want a clear division of responsibilities, and they want controlled publishing. Our three groups look like this:

Site A Authors
1. Can edit pages & assets only under /content/site-a.
2. Must request activation or deactivation.
3. Can’t edit or publish Site B.
Site B Authors
1. The same as Site A authors, but scoped to /content/site-b
Super Users
1. Can edit pages, assets, experience fragments & tags for both sites.
2. Can publish content without prior review.
3. Handle activation/deactivation requests from authors. See my post on how to set up publishing workflows.
4. Can upload and install content packages.

I am keeping things simple here. Real projects might have extra workflows, DAM-only users, regional segmentation, or compliance constraints. But the pattern remains consistent.

From RBAC to RepoInit

Once the RBAC model gets defined, RepoInit becomes the mechanism for rolling it out. You define groups and permissions in code. And let AEM apply them during deployment.

This approach keeps your access control predictable and repeatable as the project evolves.

Creating Groups With RepoInit

Our RepoInit script will go in the config.author runmode. Usually this would be a .cfg.json file. But for RepoInit, a .config file is better for readability. It will follow this structure.

org.apache.sling.jcr.repoinit.RepositoryInitializer~mysite.config

The first two scripts we will write will be for dependencies. This is because in AEMaaCS, RepoInit scripts get applied during Build Image step. Against a repository that may not contain content and groups your script depends on.

Now, we will follow the same structure when creating groups:

Create the group and set human-readable profile metadata
Add the group to Adobe’s out-of-the-box groups to give it baseline permissions
Add, allow, or deny permissions to achieve the specific access model you designed

Below is a walkthrough of each step using our fictional roles.

Step 1: Create the Groups

Each group gets an ID, friendly display name and description. This keeps the AEM UI clean and gives administrators clarity when assigning users.

Once completed, the groups show up in the groups dashboard. With friendly names and helpful descriptions.

Step 2: Assign Baseline Permissions Through OOTB Groups

Adobe provides several built-in groups that already contain common permissions:

content-authors
dam-users
workflow-users

Instead of redefining everything from scratch, we attach our groups to these foundations.

Step 3: Apply Group-Specific Permissions

Now that each group has baseline access, we tweak the final permissions. By allowing and denying specific rights.

Authors: Deny Replication & Prevent Cross-Site Editing

Inspect the permissions for the OOTB content-authors group. You will find that it can edit and replicate content under the /content path.

And the dam-users group can edit and replicate content under /content/dam.

Since our groups inherit these permissions, we will need to deny them first. Then allow them back to the specific content paths the groups will own. Minus the replication. Here is the next script.

ⓘ Note the delete ACL for <authorizable> instruction. I find this instruction helpful because it will wipe the slate clean before I applying the new ACLs. This helps avoid orphan access control entries. And this is why I use the follow up instruction allow jcr:read on home(authorizable) instruction. Because by default group members can read their group properties. Which the delete instruction removes.

Super Users: Allow Content Package Upload & Install

In this fictional example, the Super Users can edit and replicate content for either site. Additionally, they can edit experience fragments and tags. Something site authors cant. So far, the OOTB group permissions cover these requirements.

If there were more sites, we could follow the same pattern above and restrict super users to A & B only. But for this simple example, we are going to leave it at that.

The only thing we need to allow is content package installs. Which is not covered by any of OOTB group permissions.

Why Choose RepoInit?

Over the years, several tools have popped up to help manage permissions in AEM. Some common ones include:

All these tools can work, and many teams have used them with success. That said, RepoInit has a few advantages that make it a strong default choice today.

Built into AEM: RepoInit is part of AEM itself, so there is no need to install or maintain extra tools.
CI/CD friendly: RepoInit lives in source control and deploys with the pipeline. Making permission changes easy to review and track.
Declarative approach: RepoInit describes the final permission state you want. Which helps keep environments consistent.
Fewer dependencies: Using RepoInit avoids adding extra bundles or configurations. Each of which must get tested and upgraded on an ongoing basis.
Cloud ready: RepoInit works in both AEM as a Cloud Service and on-prem. Aligning with Adobe’s supported patterns.

That said, I have already used it twice. Once with Azure Entra ID SAML on-prem. And a second time with Adobe IMS on AEMaaCS. See my post on how to configure author access on AEMaaCS.

Conclusion

Access control in AEM is not about tools first. It starts with understanding job roles and defining a clear RBAC model. Once that work gets done, RepoInit gives you a simple and reliable way to build and maintain it.

A real world project may be more complex. But the pattern I am showing here remains the same. Create a group for each role. Use the OOTB group permissions as a baseline. And finally, tweak that baseline by denying or allowing as needed.