Adobe Experience Manager builds on Adobe IMS users, user groups, and product profiles in order to provide users customizable access to AEM. Learn how to define AEM groups and permissions and how they work in concert with Adobe IMS abstractions to provide seamless and customizable access to AEM.
Now that we have our Adobe IMS users, assigned to IMS groups, providing logical grouping, and our IMS users are assigned to IMS product profiles, granting them either AEM administrator or am user access to AEM. Let’s explore how these Adobe IMS concepts manifest in AEM and how they can be used to grant and manage access in AEM. When accessing an AEM author service, you must login via Adobe IMS. And remember, in order to log into AEM author, your IMS user must be part of this AEM services, AEM user, or AEM administrator product profile. I’ll log in with my Adobe ID, which is a member of the AEM administrators product profile, which will allow us to explore parts of the AEM necessary to understand how AEM and Adobe IMS relate. So let’s check out what happened when I logged into AEM via Adobe IMS, just now. First let’s jump over to Tools, Security, Users. So we can see the user that was created in AEM based on my Adobe IMS user.
And here I am. These is an AEM has my IMS username or my email address as its username. And some of my other Adobe profile attributes have been synced down as well, such as first and last name.
Clicking into Groups, all the Adobe IMS groups are a member of are synced into AEM as AEM groups. My AEM user is added to them. This mirrors the IMS user in IMS group relationships into AEM using AEM users in am groups. So in this case, the WKND digital marketers group was automatically created on login due to My Users membership in that same name group in Adobe IMS. Adobe IMS product profiles are synced into AEM as AEM groups as well. And this is where this AEM administrators group comes from.
Don’t be worried if you have other user groups here that you don’t recognize. Any product profiles you’re part of across all experience Cloud products, are synced down into AEM as AEM groups. So the synced IMS user groups are simply organizational and don’t inherently provide any access to AEM. So where are the baseline privileges that allow me to log in, and in my case, view users and groups come from. Well, members of the AEM users product profile are automatically added to the out of the box AEM Contributors group, which provides basic read access to AEM author.
Members of the AEM administrators product profile are also added to the same named AEM group, which is AEM administrators followed by an environment specific ID. This AEM administrators group in AEM is automatically given elevator permissions, which effectively ditches AEM permission on AEM entire repository. This is a powerful level access. So I’m sure that it’s only given to those users that need it and know how to wield it. Be aware that this level of access is not equivalent to the local admin user AEM, which is more akin to a root account, nor is it exactly the same as the administrator group in AEM either. Once a user is logged into AEM, any changes to Adobe IMS, will only be synced to AEM upon the user’s next login.
New IMS, configurations: meaning membership or profile attributes are not synced in if logins occur within a certain amount of time, since the last login as defined by AEM Oak Default Sync Handler, the sync debounce is roughly 10 minutes.
Permission should only be applied to AEM groups and never AEM users directly. Users are granted access via their group memberships. Custom permission should not be directly added to the synced Adobe IMS user groups in AEM. This is because these are organizational groups managed outside the context of AEM, and are best left agnostic to the internal details of AEM. This also allows them to be reusable across experience Cloud products, nor should custom permissions be granted to Adobe product profile groups. As these are unique to each AEM environment and not portable instead AEM user groups, either out of the box or custom, should be defined in AEM an AEM permissions attached to those. Then the synced Adobe IMS user groups can be added as members, to these user groups. So the permissions flow through to their users. Essentially the Adobe IMS user groups, act as a loose flexible coupling between the users and AEM permissions. Users and organizational groups can be managed agnostic to the experience cloud product and AEM administrators can translate this user organization to actionable permissions via AEM specific user groups defined and managed in AEM itself. -