AEM User Management: Roles and Permissions | OpsBlu Docs

AEM User Management: Roles and Permissions

Manage users, groups, and ACL permissions in Adobe Experience Manager. Covers AEM as a Cloud Service and on-premise user administration, IMS...

Adobe Experience Manager uses a layered permission model that combines Adobe Identity Management System (IMS) organization-level access with AEM's internal repository-level Access Control Lists (ACLs). User management differs significantly between AEM as a Cloud Service (AEMaaCS) and on-premise/AMS deployments.

Permission model overview

AEM uses a JCR (Java Content Repository) ACL system where permissions are applied to nodes in the content tree. Access is controlled through:

  • Adobe Admin Console (IMS) -- manages who can access the AEM environment at all
  • AEM User Groups -- bundle permissions and map to IMS product profiles
  • ACL entries -- grant or deny specific privileges (read, modify, create, delete, replicate) on content paths

Permissions are additive by default. A user's effective access is the union of all groups they belong to, with explicit deny entries overriding allows.

Key built-in groups and roles

AEM ships with several predefined groups. On AEMaaCS, these map to IMS product profiles:

  • administrators -- Full access to all AEM functionality including CRXDE, OSGi console, and user management. Maps to the AEM Administrators product profile in Admin Console.
  • content-authors -- Create, edit, and publish pages and assets within Sites and Assets. Maps to AEM Users product profile.
  • dam-users -- Access to Assets (DAM) for uploading, tagging, and managing digital assets.
  • template-authors -- Create and edit editable templates under /conf. Cannot modify components or code.
  • workflow-editors -- Create and modify workflow models. Does not grant the ability to start workflows on content.
  • workflow-users -- Participate in workflows (approve, reject, complete work items).
  • tag-administrators -- Create, edit, and delete tags in the tag namespace.
  • forms-users -- Access to AEM Forms authoring and submission data.

On AEMaaCS, the admin super-user account is disabled. All access flows through IMS product profiles assigned in Adobe Admin Console.

Admin UI paths

AEM as a Cloud Service:

  1. Add users to the AEM environment via Adobe Admin Console (adminconsole.adobe.com) > Products > Adobe Experience Manager > select environment > add user to product profile
  2. Manage AEM-internal groups at Tools > Security > Groups (/security/groups.html)
  3. View and edit user properties at Tools > Security > Users (/security/users.html)
  4. Set ACL permissions via Tools > Security > Permissions or directly in CRXDE Lite at /crx/de (developer environments only)

AEM On-Premise / AMS:

  1. Create users at Tools > Security > Users > Create User
  2. Manage groups at Tools > Security > Groups
  3. Edit ACLs at the node level in CRXDE Lite: navigate to the content node, open the Access Control tab

API and service account access

AEM provides multiple API authentication methods:

  • Service Credentials (AEMaaCS) -- Generated in Developer Console for server-to-server integrations. These use IMS technical account credentials and are scoped to specific product profiles.
  • Local Development Token -- Short-lived token for developer testing, generated from Developer Console.
  • Service Users (on-premise) -- System accounts mapped to bundles via ServiceUserMapper configurations. These bypass interactive login and are used by OSGi services.
  • API Keys via Adobe I/O -- For integrations using AEM APIs through Adobe Developer Console. Scoped via product profiles.

Service credentials should be stored in your CI/CD secrets manager, not in developer accounts. Rotate when team members with access to Developer Console leave.

Analytics and tracking permissions

Installing or managing analytics on AEM requires specific access:

  • GTM/script injection -- Requires template-author or developer access to edit page templates and components under /apps or /conf. Content authors cannot inject scripts.
  • Adobe Analytics integration -- Configured via Cloud Services configuration under Tools > Cloud Services > Legacy Cloud Services or via Adobe Launch (Experience Platform Tags). Requires the administrators group or a custom group with write access to /etc/cloudservices.
  • Experience Platform Tags (Launch) -- Managed externally in Adobe Experience Platform, but the embed code is placed in AEM page templates. Template editors need access to modify the header component.
  • Data Layer -- The Adobe Client Data Layer (ACDL) is configured through component policies. Modifying data layer output requires developer-level access to component code.
  • Reports access -- Built-in AEM page analytics views require the user to have read access to the content path and membership in a group with analytics viewing permissions.

A content author can view page-level analytics data in the Sites console if their group has the analytics permission, but they cannot modify tracking configuration.

Security and SSO

  • AEMaaCS mandates Adobe IMS SSO -- no local authentication is possible for end users
  • On-premise supports SAML 2.0 SSO via the SAML 2.0 Authentication Handler OSGi configuration
  • SCIM is not natively supported; user provisioning is handled through Admin Console or LDAP sync (on-premise)
  • Enable the Closed User Group (CUG) feature to restrict published content to specific authenticated groups
  • Audit logs for user and permission changes are available under Tools > Operations > Audit Log

Further Reading

Back to top