Solved

Roles in AEM

Forum|Forum|5 years ago
October 7, 2020
5 replies
5449 views

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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by ClintLundmark

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.

...

clint

Suraj_Kamdi

Community Advisor

@carmcon

Here is the complete guide to understanding the role of users/groups in AEM.

https://docs.adobe.com/content/help/en/experience-manager-65/administering/security/security.html

Suraj Kamdi

kautuk_sahni

Community Manager

Users

Users will log in to AEM with their account. Each user account is unique and holds the basic account details, together with the privileges assigned.

Users are often members of Groups, which simplify the allocation of these permissions and/or privileges.

Groups

Groups are collections of users and/or other groups; these are all called Members of a group.

Their primary purpose is to simplify the maintenance process by reducing the number of entities to be updated, as a change made to a group is applied to all members of the group.

Refer: https://docs.adobe.com/content/help/en/experience-manager-65/administering/security/security.html

User ID	Type	Description	Recommendation
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 result of access control evaluations.

You can change the permissions granted/denied to a given user by selecting or clearing the checkboxes for the individual AEM actions. A check mark indicates that an action is allowed. No checkmark indicates that an action is denied.

Where the checkmark is located in the grid also indicates what permissions users have in what locations within AEM (that is, which paths).

Actions

Actions can be performed on a page (resource). For each page in the hierarchy, you can specify which action the user is allowed to take on that page. Permissions enable you to allow or deny an action.

Action	Description
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.

Kautuk Sahni

santhosh_kumark

Level 6

Hi @carmcon

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.
https://helpx.adobe.com/experience-manager/kt/eseminars/gems/aem-managing-content-with-template-editor.html

https://docs.adobe.com/content/help/en/experience-manager-64/administering/security/security.html

ClintLundmarkAccepted solution

Level 3

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.

...

clint