A Map to Navigate through AEM as a Cloud Service User Administration
How to not get lost in the Adobe Admin Console
A couple of years ago, I was tasked to design a user management concept for a larger AEM as a Cloud Service (AEMaaCS) project. I must admit, I was more than just a bit confused by the new concepts.
Sure, I was used to design access control concepts for AEM on premise. But AEMaaCS uses the common Adobe Identity Management System (IMS) for authentication. And IMS adds a few layers of complexity to user management.
The official documentation was — let’s say — fragmented. I learned how to create a new Product Profile — I did not learn what a Product Profile is and why I would need one in the first place.
Luckily, I got a grip on the concepts, and suddenly everything made sense.
In this article I explain the fundamentals and share with you a few best practices, so that you can plan — and do not waste time on trial and error as I had to.
IMS as a global Identity Provider
IMS is designed to administer more than just AEM. In fact, you use it to administer all Adobe Cloud Solutions: From access control for Adobe Analytics over license management for Photoshop to controlling who can spend credits on Adobe Stock images. The benefits of a central IdP are obvious: You only need to manage one user account — and this user account can then seamlessly access (almost) all Adobe solutions. The more systems you integrate the more useful you’ll find it.
Today it’s quite common, that organizations already have an IdP or Single Sign On (SSO) system installed. IMS integrates nicely into most of them. IMS delegates the authentication to these external IdPs.
What makes IMS more complex is that it adds additional roles, such as:
- IMS System Administrator,
- Product Administrators for each product you manage in IMS,
- Profile and Group Administrators to manage roles in the applications,
And of course, we still have Users assigned to these roles.
The Admin Console
IMS is the Adobe backend for identity management. The “Admin Console” at adminconsole.adobe.com is the user interface for IMS. I will use the two terms interchangeably, here. This is not 100% correct, but a good enough simplification.
A High Level View
To make the description more tangible, let’s assume our system consists of four solutions in three tiers:
- Microsoft Azure AD as a company-wide SSO and IdP
- Adobe IMS works as an integration layer of the IdP and the applications.
- Adobe Experience Manager as a Cloud Service (AEMaaCS) and Adobe Analytics
A Complete Map of Almost Everything
The diagram below breaks down the individual entities in Adobe IMS and their relations.
I know — that’s a lot to digest. Let’s focus on the red box and the entities defined here.
IMS System Administrator
This role can manage the whole IMS system. It can create new Users, Profiles, Groups, and even new System Administrators.
Important note: This role does not automatically have access to the applications. But the role can be used to gain access to any application.
Best practice: This is an immensely powerful role that should be owned by only a handful of people. This role is a superior role that controls multiple applications. It makes sense to assign the role to a cross-functional IT service department — if you have one in your organization.
You can find and create Administrators below Users/Administrators in the Admin Console.
Note: When the first cloud application is provisioned, Adobe assigns the person mentioned in the license contract to that role. This can be a CMO or CIO, not involved actively in the project. So, the first task of the “System- Administrator-In-Charge” would be to help that business owner to delegate that role.
IMS Product Administrator
This role is responsible to manage access to a single application — in our example we’ll have an AEM Product Administrator and an Analytics Product Administrator.
A Product Administrator User can create new Product Profiles and assign Users and Groups to the Profile.
A Product Administrator Admin can entitle other Users as Product Administrators with similar rights.
You’ll find the settings for Product Administrators below Products/Admins.
Product Profiles
Product Profiles are like a groups that users can be members of and can be used instead of groups in smaller installations. Membership in a Product Profile allows basic access to the application. How a specific profile is interpreted within that application differs from application to application. In case of AEM, the profile is mapped to a group in AEM. You can later assign privileges (Access Control Lists, ACLs) to this mapped “profile group” within AEM (though it’s not necessarily best practice).
By default, each AEM instance comes with two built-in profiles (see screenshot further down):
- AEM-Users-xxx
- AEM-Administrators-xxx
(“xxx” stands for a unique identifier)
A Product Administrator can add new Product Profiles such as “SiteX-US-Copywriter”. These profiles would then be mapped to AEM groups with the same names and can be assigned privileges to.
You can use profiles in smaller, stand-alone installations, only. But usually you would use IMS groups — especially when you integrate an external IdP. See chapter “Profiles or Groups?” on a longer discussion when to use what concept.
Note: You’ll find the Product Profiles in the Admin Console under the Products / <Product> / Product Profiles.
Unique identifiers — Bug or Feature?
IMS adds a unique identifier to differentiate roles with the same name on different environments. This is necessary, because IMS transmits all(!) profile names and all(!) group names a user is member of to AEM when that user logs in: It transmits profiles from other AEM instances and even profiles from other applications.
For example, you can see the “Administrators” and “Users” groups from Development and Stage in the AEM Production instance:
You can even find groups from other solutions, such as Photoshop in AEM:
It should be obvious, that you do not want developers with admin-access to the development instance to also have access to the production system. So — of course — the names need to be distinct.
But why does IMS synch non-related profiles (and groups) in the first place? When I first encountered this, I thought this was a bug. Only later I realized this is also a feature. There are several good reasons to synchronise all groups:
- When integrating two solutions, it may be necessary to know what roles a logged in user has in other applications. For example, in one project, we only show the “Adobe Stock” icon in the AEM Assets console, when the user is in a particular group. So, we needed to know about this unrelated group in AEM.
- When you have a larger number of AEM groups, it can become tedious and error prone to manually associate all of them with the according product. This is especially true, when you are dealing with an external IdP — like Azure AD in our example: When creating a new group in Azure AD, it is automatically synchronised to AEM without having to associate explicitly.
On the other side, you are quickly accumulating a larger number of groups in AEM. Debugging or administering groups — especially with cryptic identifiers — is not an enjoyable undertaking. But if you follow a few best practices, you’ll anyway manage users in IMS or the external IdP, only and you’ll rarely see the “clutter” in AEM.
Best Practice: Do not use built-in profiles!
In any case, the best practice is to not (!) use the built-in profiles. Create custom Profiles or Groups instead — with more meaningful names, such as “AEM-Prod-SiteX-US-Copywriter” or “AEM-Prod-Systemadmin”
I only use built-in groups on sandbox instances for quick demos or when bootstrapping a new instance. But never in production.
Default AEM groups
IMS profile names do not have any meaning in AEM. All profiles are translated into AEM groups with the same name when a user first logs in. AEM also adds a default group. So, the semantic of a group is defined by the ACLs that are assigned (later) to the groups in AEM.
Well… almost. There are two hidden features in AEM:
- By default, all users are added to the “Contributor” group is AEM. This is true for the “AEM Users-xxx” profile but also for any other profile you create.
- The default profile “AEM Administrators-xxx” is hard-coded to map to an administrative group in AEM. This is used for bootstrapping: Somehow an administrator must initially gain access to the system.
The default group all users are member of is defined in the OSGi configuration of the DefaultSyncHandler in AEM. It is preset to “Contributor”.
Note that the configuration is using an environment variable. If you want to re-define it, add an environment variable with that name in Cloud Manager. Do not provide a custom OSGi config.
Example:
If you create a Product Profile “AEM-Prod-SiteX-US-Copywriter”, a user in that Profile would be member of the AEM groups “AEM-Prod-SiteX-US-Copywriter” and “Contributor”.
AEM Administrator Profile
AEM grants “administrator”-privileges to the admin-console group “Administrators-XXX” through an OSGi configuration: org.apache.jackrabbit.oak.security.authorization. AuthorizationConfigurationImpl
The environment variable (coming from “build-time”) contains the admin-console group-name in the variable $[env:aemCloudAdministrators;default-administrators] .
This variable is then assigned to the “administrative Principals” in AEM though the OSGi-config below.
PID = org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
administrativePrincipals = [administrators, $[env:aemCloudAdministrators;default=administrators]]
feature = [com.day.cq:cq-quickstart:slingosgifeature:security-authorization_skyline:6.6.0-V21856]
importBehavior = besteffortProfile Administrator
The Product Administrator can delegate the management of users in a certain Product Profile to one or more Profile Administrators.
For example, the profile “AEM-Prod-SiteX-US-Copywriter” could have a dedicated administrator whose job it is to manage users in that profile.
Again: “Admins” in the Admin Console to not allow to use an application. It allows to add users to a profile that then can use the application.
As a rule of thumb: If it is named “Admin” in the Admin Console, this usually is about user management. If it says “Administrator”, this is about managing the application.
IMS Groups
Ok — profiles have members and can be associated with privileges… But isn’t that usually the definition of a “group”? Then what are IMS Groups about?
In the Admin Console, an IMS Group is more than a profile:
Profiles are associated with one — and only one — specific application. An IMS Group — in contrast — is an overarching concept: It allows access to multiple applications.
For example, we could define a group “Marketing Manager” that allows “approve” privileges in AEM and “create report” in Adobe Analytics.
To achieve that, an IMS Group is associated with one or more Product Profiles.
In the example above, the User Group “AEM-PROD-SiteX-Germany-Copywriter” is assigned to the Product Profile “AEM Users-f4d7030374”. This means, all Users in that group have access to the application the profile is assigned to.
Which environment (prod, stage, or dev) the user has access to, is not apparent from that Profile name. Remember, that I advised you to not use the built-in names? Now you know why…
IMS Group Admins and Users
IMS Groups have Users as members (obviously). IMS Groups also have group Admins. Admins can add and remove Users to and from that IMS Group. IMS Group Admins can be assigned by an IMS System Admin or by another IMS Group Admin in that group.
Granularity of Groups
Being able to combine access to multiple applications in one group can ease the onboarding of new team members. Instead of assigning each new team member to dozens of groups, you’d define a group “Marketing Department”, that grants access to all applications at once…
… or at least this is the theory.
In my personal experience, I have rarely seen a case where more than two users share the exact same role description: Emily is a marketing specialist with access to AEM and Analytics, Connor just needs access to AEM, and Joanne only needs access to Analytics and Photoshop.
Let’s assume we had a group “Marketing Specialist”. I bet that each time you’ll onboard a new user to the team you would look up what applications that group allows access to and which privileges it grants. Such group names are not very self-descriptive.
I prefer fine-grained single-product groups with more descriptive names. Like “AEM-Prod-SiteX-US-Copywriter”, “Photoshop-User” or “Analytics-PROD-SiteX-Viewer” and explicitly assign these roles to new team members, in other words: a 1:1 mapping between groups and profiles. This also better supports the principle of least privilege [1].
Groups vs. Profiles
User Groups and Product Profiles are similar concepts. Both allow delegation of user management, and both eventually map to AEM groups (see detail below). In the last chapter we learned that it can be an advantage to have fine-grained groups that only allow access to single applications.
Groups vs. Profiles
User Groups and Product Profiles are similar concepts. Both allow delegation of user management, and both eventually map to AEM groups (see detail below). In the last chapter we learned that it can be an advantage to have fine-grained groups that only allow access to single applications.
Does that mean, we can use Profiles, only — and forget about groups?
Unfortunately… no. Look carefully at the illustration above — especially the blue areas. We can configure an IdP like Azure AD to synchronise Azure AD Groups into IMS groups. We can then associate the synched group with a profile. We cannot directly map AD Groups to IMS Profiles. So, when using an external identity provider, we always deal with groups and profiles.
Also, groups can contain multiple profiles, only. Unlike in AEM, an IMS group cannot be a member of another IMS group.
Sidenote: Groups and users from external identity providers are marked with two arrows (see screenshot below).
In short:
User Groups:
- can be assigned with more than one product profile,
- can by synchronised from an external identity provider.
Product Profiles:
- are application-specific,
- can not be synchronised from an external IdP.
Transitivity of Groups and Profiles
“Transitivity” in general means that a certain property is inherited from an indirect membership in a group or profile.
Transitivity in AEM
In AEM it is common to nest groups.
Example:
Emily is a member of a group „AEM Marketing“. The group „AEM Marketing“ in turn is a member of the group „AEM-copywriter“. Then, Emily also is a member of „AEM Copywriter“.
Transitivity in IMS
IMS does not support nesting of groups. Though groups can be associated with profiles. Thus, indirect membership in a profile is possible in IMS. If you want to have nested groups, you’d model them in AEM. In IMS you can still place the user in the outer group. Inheritance of the privileges is then calculated in AEM.
Note: A user must be at least a member of one Profile of the AEM instance he wants to log in. This usually is an indirect membership via some base group.
Let’s illustrate this with a few examples:
Example (1)
- Emily is a member of the IMS Group “Marketing”.
- The group “Marketing” — in AEM — is a member of the group “AEM-copywriter”.
Emily cannot log in because her account is not associated with any Profile.
Example (2)
- Emily is a member of the IMS Group “Marketing”.
- Emily is also member of the IMS Profile “AEM-base”.
- The Group “Marketing” in AEM is member of the IMS Group “AEM-copywriter”.
- Emily also is in the Profile AEM-base.
Emily can log in because she is a member of an AEM Product Profile in IMS. Her user account is synchronized, as is the “Marketing” Group and her memberships in that Group. The Profile “AEM-base” is also synchronized as an AEM Group. And Emilie will be a member of that group in AEM.
We have learned, however, that Profiles cannot be synchronized with an external IdP (e.g. Azure AD) so this is not good practice, as it would require manually placeing all users into profiles in IMS.
Example (3)
We have the same effect when the Profile is not associated with the account but with a group: As Emily is a member of “Marketing” which is associated with the Profile “AEM-base”, she can log in and all Groups and Profiles are synchronized.
Best Practice: Associating a Base Group with a Profile
A user only needs to be a member in one Product Profile. This can be indirect via group membership.
In the example below, a “Base” group was created that all users are members of. This group acts as a gate keeper to the application (and to define a few basic privileges in AEM). The actual privileges are associated with more business-specific groups.
Note, I have created a Group “AEM-base” and a Profile “AEM-base-profile”. As both are mapped to AEM Groups, they cannot have the same name, thus the suffix “-profile”.
But why create a Profile and a Group? Well, a user needs an association with an AEM Product Profile to be able to log into AEM. But Profiles cannot be synchronised from an external IdP, so we create a Group that can be synchronized. It acts as a proxy.
As mentioned earlier, all groups from IMS are synchronized to AEM when logging in. It is not necessary to associate all groups with profiles. A user needs to be associated with one profile, only. We achieve that by associating only the “AEM-base” group with the profile.
Associating only one group with a profile is a good practice: Associating external groups with profiles is a longer process that you do not want to have in your daily processes: You would set up the group in Azure AD, wait an hour until the group is synchronized into Adobe IMS, open the Admin Console, and assign the User Group to the Product Profile.
When you have an external IdP you usually want to manage users and groups in that IdP, only. Logging into two systems to set up a new group is cumbersome. By only associating an “AEM-base” group you need to do that only once when setting up the integration. Other external groups created later can be managed in the external IdP, only.
On the flipside, this means: All users must be assigned to the specific business-defined groups and explicitly to the “AEM-base” group. But that is only a little overhead.
Synchronizing and Caching
You probably will not get the setup right on the first attempt. You will then realize that your corrections will not apply either.
This can be quite frustrating. You did everything right — just as I recommended — yet still it does not work.
Do not despair. AEM caches group memberships of a user for some 20 minutes or so. So, if you correct the user accounts, you need to wait 20 minutes before the next login. The expiration time is set in the DefaultSyncHandler OSGi config (see above). While you are in “learning” mode, it can help to reduce the expiration time to get better feedback.
Assigning Privileges
IMS is responsible for identity management and group memberships, only. Privileges are managed in the applications, e.g., by assigning Access Control Lists (ACLs) to the synched AEM groups.
External Groups are synchronized to IMS every hour or so. The IMS groups, in turn, are synchronized to AEM when a member of that group logs into AEM the first time.
Obviously, you can only assign ACLs to groups after they have been created in AEM. If you have dozens of groups with a sophisticated access control schema, you do not want to manually synchronize them to AEM by manually logging in with users. Also, you might want to test the ACL on a lower environment first before rolling them out to production.
What you want is some automation and scripting. Luckily, there are a few options:
- I recommend using the Access Control Tool by Netcentric [3]
- For smaller projects, Sling Repository Initialization (repoinit) scripts can be an alternative [2].
In any case, you’ll mark the groups as external, so that AEM knows to match the IMS- and AEM groups and not consider them as separate entities and report a naming conflict.
I’ll do a more comprehensive comparison and a how-to in a later article. Please follow me to get notified.
AEM Administration
How you manage the ACLs within AEM depends on the tool you use. In the case of repoinit or the Netcentric AC Tool, you’d manage the ACLs as part of the code base in Git. So, managing them would require access to Git — and the ability to run a deployment pipeline. I also have seen projects that have built their own tools. In this case you would need to be an AEM administrator — so a user that is member of the “AEM Administrators-XXX” profile (or a member of a group that is associated with that profile).
Mixing IMS and External Groups
I usually recommend directly using IMS profiles for technical / administrative roles, such as Cloud Manager roles or AEM administration.
Groups from external IdPs should be used for business users that are more frequently on- and offboarded.
This is mostly for practical reasons: Often the external IdP is managed by a different department. This is great for daily business tasks, but an impediment for system administration. Here I prefer to be able to manage the individual applications more autonomously.
The decision depends on the organization, the division of the departments, the SLAs the offer and the global policies.
Dos and Don’ts
Now that we know what is behind the concepts let me share a few lessons I have learned:
Do not use trial and error.
The most widespread problem is that users don’t have time to get familiar with the IMS concepts and accumulate roles in their accounts until they eventually can perform the tasks they are supposed to. Please don’t! Read this article to the end. It’s easier than you think. During this “trial and error” phase, they accumulate roles they do not actually need. This violates the principle of least privilege [1].
Do not add system administrators.
During trial and error, users also often add the System Administrator role to accounts to be onboarded. Either in despair or by simply replicating group memberships of users that are known to work. The crux with system administrators is, they are almighty — something very few should be. System administrators, not knowing what they do are opening the flood gate for more admins. This system administrator will eventually create more system administrators which in turn create even more. You have now completely given away control over access to the application.
Do not copy and paste.
This brings us to the next anti-pattern: Copy & Paste users. Let’s say, you want to onboard Connor as a new external copywriter for the team. Connor needs access to AEM, only. Emily, a senior marketing specialist, already has access to AEM, so you ask your service desk (assuming they own the user management) to add Connor to the same groups as Emily. Little did you know that Emily also has access to Adobe Analytics and is working as Group Administrator. So now Connor accidentally has these rights, too. Connor can work with AEM — but also have access to information he shouldn’t have.
Be specific.
Instead of copy and pasting, be specific to what applications a user needs to have access. Not more and not less.
Document Groups.
To be able to exactly specify the groups the users need to be member of it is important to document the groups in detail. Document the groups as part of the system documentation in a place where it is easily accessible. Store in a way the documentation can easily be updated, such as a Wiki or SharePoint. Read-only formats such as PDF certainly will never be updated. Outdated documentation will be ignored soon, and people soon revert to copying users.
A good documentation contains:
- Self-describing group names, such as AEM-Prod-SiteX-US-approver
- A brief description in plain English of what each group entails.
- A concise table that lists all groups and resources and their privileges.
Audit regularly.
Regularly audit user accounts and what access they have. Define a role that is responsible for this governance task. Disable or remove accounts no longer required. Remove privileges / group memberships that are no longer required.
Define a Meta Concept
An access control concept always needs to be embedded into the context of the organization who is using it.
Before diving into an implementation of immediate requirements it is advised to take a step back and analyze the more high-level context:
- Where and how are normal groups maintained (IMS or external IdP)
- Who is responsible of administrating the IMS at what level?
- How do you manage system-, profile-, and group admins?
- How do you manage ACLs?
- How do you name groups and profiles?
- How do you manage groups on lower environments?
- How do you test access control?
- …
If you understand the context, it is easier to choose the proper IMS concepts.
Define a Consistent Naming Convention.
When a system becomes more complex, e.g., when you host multiple sites on the platform, it is important to have a good naming convention for groups. The convention — of course — depends on the business requirements.
For AEM, I have good experiences with starting with a convention like so:
<APP>-<Environment>-<Site/Brand>-<Region>-<Role>
Where the Site-Region part is aligned with the primary access control domain (the path where you put most of the ACLs).
For example:
AEM-Prod-AcmeClothing-DE-Copywriter
Hints that the group describes a copywriter role on the path /content/AcmeClothing/de.
Defining such a naming structure has several advantages:
- It’s comprehensible and self-descriptive,
- you can easily use auto-completion when looking for a specific role in the IdP, IMS or in AEM,
- in the best case, you describe the roles only once and apply them to all sites in your system,
- groups can be automatically created with tools and scripts. You can manage all your hundred sites with one definition file.
Conclusion and Best Practice
IMS provides you with a broad range of options to set up a sophisticated, fine granular concept of system- and user management. This can be a bit intimidating, first.
In practice though, you’ll only use a fraction of IMS’ capabilities. Here is what I usually do:
- Manage normal business users in the external IdP.
- Delegate group management to business admins in the external IdP (for on- and offboarding).
- Manage administrative roles directly in Adobe IMS.
- Do not delegate group/profile administration in IMS — usually, a Product Administrator can perform such tasks.
- Do not allow more than a handful of global IMS System Administrators.
- Perform regular audits of users and groups in Adobe IMS.
- Do not use the built-in AEM profiles.
- Use the “AEM Administrator-xxx” profile only for the initial setup of your own profiles.
- Do not use groups overarching multiple applications.
- Only create one “AEM-Prod-base-profile” and assign to it to the “AEM-Prod-base” group. All other groups do not need a profile. (Do the same for the lower environments).
- Associate ACLs only to AEM groups that are synchronised from IMS groups (not to profiles).
- Design a self-descriptive naming convention up-front. Do not invent group names ad hoc.
- Create groups in the external IdP and groups with the exact same name in the ACL management tool of your choice (e.g. netcentric AC tool).
References
[1] https://en.wikipedia.org/wiki/Principle_of_least_privilege
[2] https://sling.apache.org/documentation/bundles/repository-initialization.html
[3] https://github.com/Netcentric/accesscontroltool
[4] https://helpx.adobe.com/enterprise/using/admin-roles.html
