You spent countless hours developing, testing, and putting together an awesome AEM site. The whole time you work as 'admin'. You make it to QA and the question will arise. "How do we grant content authors access?"
In previous projects, you dealt with local AEM groups. Or you had an LDAP integration. If you find yourself in AEMaaCS now the question is "What is IMS and how do I grant content authors access?"
Create a User in IMS
Adobe's Identity Management System allows customers to manage all Experience Cloud users in a single unified console. You can create users in IMS or you can sync with an external directory.
Let's create a user in IMS. Go to the Admin Console and click on the Add Users Quicklink.
You can use any email, as long as it is not already in the current directory. Once you have entered the email select the product profile. In this case, I am adding this user to the AEM Users product profile that belongs to my Stage Author.
By adding the user to the AEM Users product profile, you have granted them read-only access. This IMS group gets membership in the Contributors group in AEM.
The user can log in now using the email provided. If the email is not associated with an Adobe ID, they may create a new Adobe account.
Create a Group in IMS
Now our user has read-only access. We need to set up the group that we will use to grant them authoring permissions. To create an IMS group navigate back to the Admin Console. Click on the Users tab on the top and then the Users groups link on the left-hand navigation.
Throw in an "IMS" suffix so that when this group shows up on AEM we can identify it as a group that came in from IMS. Once you create the group, navigate to the group and click on the Users tab. Add the user you created to this group.
⚠️ Ask the user to log in. AEM is not aware of new IMS groups until a user logs in. At that point, the group will get created in AEM and linked via a rep:externalId. |
Create the Authors Group in AEM
You are leaving IMS now and navigating to your AEMaaCS author instance. You are performing the following steps
Navigate to Tools | Security | Groups
Create a new group called "My Site Authors"
Go back to the Groups dashboard and locate the "Authors" and "DAM Users" groups.
Add the "My Site Authors" group as a member of each "Authors" and "DAM Users"
Assign permissions to the local "My Site Authors" group as necessary.
Creating the Group With Repository Initialization (repoinit)
The above steps are simple enough if you are dealing with one group and one environment. Chances are you will have many groups and 3 environments. You need to persist these changes to source control. The best way in AEMaaCS is Repository Initialization (repoinit).
⚠️ The current version of the AEM project archetype I'm using is 30. If you are using this you may notice there are 2 Repo Init config files, a .json, and a .config.
PR #806 was already merged. In case you see the duplicates, delete the JSON file. For the repo init scripts JSON doesn't work well. JSON does not allow multi-line in the editor. |
So let's append this to the end of the RepositoryInitializer-mysite.config file
# this group will have as one of its members, the IMS group.
create group mysite-authors with forced path /home/groups/mysite
set properties on authorizable(mysite-authors)/profile
set givenName to \"My Site Authors\"
set aboutMe to \"The bridge between IMS and AEM local groups.\"
end
# these are OOTB groups that do not exist in buildImages pipeline step
create group content-authors
create group dam-users
# add our local group to the OOTB groups used as baseline
add mysite-authors to group content-authors
add mysite-authors to group dam-users
# set ACL for our local group
set ACL for mysite-authors
deny crx:replicate,rep:write on /content
allow crx:replicate,rep:write on /content/mysite
allow crx:replicate,rep:write on /content/dam/mysite
endThe script does the following
Create the group and give it a friendly name and description.
Creates the OOTB groups. This is only because these groups will not exist when in the Build Image step of Cloud Manager's pipeline. This will not have any ill effects if the groups already exist.
Make the group a member of the OOTB groups, giving the group a baseline set of permissions.
Tweak the baseline permissions. In this case, we scope down the crx:replicate and rep:write to the relevant site folders.
Connect the IMS and AEM Groups
The last step is the most important because it is the glue between IMS and AEM. Within AEM, navigate to Tools | Security | Groups and locate the "My Site Authors IMS" group. Edit its list of members and add "My Site Authors IMS".
Members of the "My Site Authors IMS" group will now get all the permissions given to "My Site Authors".
You may be wondering why I didn't make this step part of my RepoInit script. It's a chicken or the egg problem. As noted earlier, a user had to log in for the IMS group to get pulled into AEM. RepoInit will fail without it. And RepoInit can't create it because IMS users and groups link via a rep:externalId. A property that it knows nothing about.
Conclusion
Here I used Authors as an example. This will work with any conceptual grouping you want to put in place. It could be "Template Authors" or "Tag Managers". The important takeaway is this: the IMS group is a member of the local group. The ACL is set up for the local group. Henceforth, add users to their respective groups within the Admin Console. Thus you will have granted them the rights and privileges for that local group.