I'm looking to better understand best practices with user roles in AEM as my company is in the process of migrating to AEM from an older CMS. I've seen roles described as "Super Author" and "Author" and I'm looking to better understand what specific tasks are intended for Super Authors vs Authors vs Developers to own. We're hoping once we're migrated over Authors could be our creative and design department, which is not how we currently operate. Curious how other companies are using AEM and best practices. Thank you.
AEM is very flexible for how permissions and "roles" are applied. Your approach will likely depend on how you want to manage users and what features of AEM you deploy. Because of the flexibility, a role based solution can easily get complex. We have decided to keep it fairly simple.
We use groups to define a role based, usually, on job responsibility or department. All of our authoring users are at least "contributors". We define a role like "Marketing" or "Customer Service". A group is created named "Marketing". The Marketing group is a member of Contributors. Marketing employees that need the ability to edit content in AEM are added to the Marketing group. That group in turn is given permission required for marketers to manage content - whatever that may be. In the Marketing case they might have full editing and replicate permissions to all content or even be a member of the built in group "authors". Other roles may be limited to edit and replicate just portions of the content that applies to their job function or role.
We also use LDAP to manage the users and groups so they can be managed centrally using existing user credentials.
Hopefully that is helpful to you or someone else looking.
Hi @CarmCon the below help document explains in detail:
Let us know if this helps.
There are content authors and template authors in aem. The content authors group responsible for content editing. Requires read, modify, create and delete permissions. Template authors will be able to configure policies, initial content and layout by selecting template and click on edit button.
|admin||User||System administration account with full access rights.||Adobe strongly recommends that the password for this user account be changed from the default.|
|Default password: admin||This account is used for the connection between AEM WCM and CRX.||Preferably upon installation, though it can be done afterwards.|
|If you accidentally delete this account, it will be re-created upon repository restart (in the default setup).||Note: This account is not to be confused with the admin account of the CQ Servlet Engine.|
|The admin account is a requirement of the AEM platform. As a consequence, this account cannot be deleted.|
|anonymous||User||Holds the default rights for unauthenticated access to an instance. Per default this holds the minimum access rights.||Please avoid deleting or disabling this account, as it will negatively impact the functioning of author instances. If there are security requirements that mandate you to delete it, make sure you properly test the effects it has on your systems first.|
|If you accidentally delete this account, it will be re-created upon startup. It cannot be permanently deleted, but it can be disabled.|
|author||User||A author account allowed to write to /content. Encompasses contributor and surfer privileges.||Adobe recommends that either the account is deleted completely, or the password changed from the default.|
|Default password: author||Can be used as a webmaster as it has access to the entire /content tree.||Preferably upon installation, though it can be done afterwards.|
|This is not a built-in user, but another geometrixx demo user|
|administrators||Group||Group that gives administrator rights to all its members. Only admin is allowed to edit this group.||If you set a 'deny-everyone' on a node, the administrators will only have access if it is enabled again for that group.|
|Has full access rights.|
|content-authors||Group||Group responsible for content editing. Requires read, modify, create and delete permissions.||You can create your own content-author group(s) with project specific access rights, provided you add read, modify, create and delete permissions.|
|contributor||Group||Basic privileges which allow the user to write content (as in functionality only).|
|Does not allocate any privileges to the /content tree - these must be specifically allocated for the individual groups or users.|
|dam-users||Group||Out-of-the-box reference group for a typical AEM Assets user. Members of this group have appropriate privileges to enable uploading/sharing of assets and collections.|
|everyone||Group||Every user in AEM is a member of the group everyone, even though you may not see the group or the membership relation in all tools.||Do not modify or delete this group.|
|This group can be thought of as the default rights as it can be used to apply permissions for everyone, even users that will be created in the future.||Modifying this account has additional security implications.|
|tag-administrators||Group||Group that is allowed to edit tags.|
|user-administrators||Group||Authorizes user administration, that is, the right to create users and groups.|
|workflow-editors||Group||Group that is allowed to create and modify workflow models.|
|workflow-users||Group||A user participating in a workflow must be member of group workflow-users. This gives him or her full access to: /etc/workflow/instances so that he or she can update the workflow instance.|
|The group is included in the standard installation, but you must manually add your users to the group.|
|Permissions in AEM|
|AEM uses ACLs to determine what actions a user or group and can take and where it can perform those actions.|
|Permissions and ACLs|
|Permissions define who is allowed to perform which actions on a resource. The permissions are the re...|
|You can change the permissions granted/denied to a given user by selecting or clearing the checkboxe...|
|Where the checkmark is located in the grid also indicates what permissions users have in what locations within AEM (that is, which paths).|
|Actions can be performed on a page (resource). For each page in the hierarchy, you can specify which...|
|Read||The user is allowed to read the page and any child pages.|
|Modify||The user can:|
|modify existing content on the page and on any child pages.|
|create new paragraphs on the page or on any child page.|
|At the JCR level, users can modify a resource by modifying its properties, locking, versioning, nt-modifications, and they have complete write permission on nodes defining a jcr:content child node, for example cq:Page, nt:file, cq:Asset.|
|Create||The user can:|
|create a new page or child page.|
|If modify is denied the subtrees below jcr:content are specifically excluded because the creation of jcr:content and its child nodes are considered a page modification. This only applies to nodes defining a jcr:content child node.|
|Delete||The user can:|
|delete existing paragraphs from the page or any child page.|
|delete a page or child page.|
|If modify is denied any subtrees below jcr:content are specifically excluded as removing jcr:content and its child nodes is considered a page modification. This only applies to nodes defining a jcr:content child node.|
|Read ACL||The user can read the access control list of the page or child pages.|
|Edit ACL||The user can modify the access control list of the page or any child pages.|
|Replicate||The user can replicate content to another environment (for example, the Publish environment). The privilege is also applied to any child pages.|
I guess this is what you are looking for.