ÃÛ¶¹ÊÓƵ

Transcript

Now that we have our ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ IMS relate. So let’s check out what happened when I logged into AEM via ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ profile attributes have been synced down as well, such as first and last name.

Clicking into Groups, all the ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ IMS. ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ IMS user groups can be added as members, to these user groups. So the permissions flow through to their users. Essentially the ÃÛ¶¹ÊÓƵ 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. -