Managing Users and User Groups managing-users-and-user-groups

Overview overview

In AEM Communities, in the publish environment, users can self-register and edit their profiles. Given the appropriate permissions, they may also

Users registered in the publish environment are generally referred to as community members (members) to distinguish them from *users *in the author environment.

Permissions are granted by assigning members to one of the member (user) groups dynamically created when the community site is created or modified from the author environment. When working from the author environment, members are visible from the publish environment by means of the tunnel service.

By design, members and member groups created in the publish environment should not appear in the author environment. Users and user groups created in the author environment are similarly intended to remain in the author environment.

When users on author and members on publish come from the same list of users, such as synchronized from the same LDAP directory, they are not considered the same user with the same permissions and group membership in both the author and publish environments. The role(s) of members and users must be established separately on publish and author, as appropriate.

For a publish farm, registration and modifications made on one publish instance need to be synchronized with other publish instances in order for them to have access to the same user data. For details see User Synchronization, which includes a section describing What Happens When….

Contribution Limits contribution-limits

In order to protect against spam, it is possible to limit members’ frequency of posting content. Further, it is possible to automatically limit the contributions of newly registered members.

For details, see Member Contribution Limits.

Dynamically Created User Groups dynamically-created-user-groups

When a new community site is created, new user groups are dynamically created with uniquie ids (uid) and permissions appropriate for various administrative functions necessary to manage the community site either in the author environment (see Author Group Roles) or the publish environment (see Publish Group Roles).

The names of the groups are generated from the name given the site during community site creation. The unique ids avoid naming conflicts for similarly named community sites and community groups on the same server.

For example, if the site name were “engage” for a site titled “We.Retail Engage”, then one of the user groups created would be:

Author Environment author-environment

Tunnel Service tunnel-service

When using the author environment to create sites, modify site properties and manage community members and member groups, it is necessary to access users and user groups registered in the publish environment.

The tunnel service provides this access using the replication agent on author.

The Communities Members and Groups consoles are for the sole purpose of managing users (members) and user groups (member groups) registered only in the publish environment.

To manage users and user groups registered in the author environment, use the Security console

Author Group Roles author-group-roles

System Administrators system-administrators

Members of the administrators group are system administrators who are able to perform the initial setup of an AEM installation for both the author and publish environments.

For demonstration and development purposes, the administrators group has a member whose userid is admin and password is admin.

For production environments, the default administrators group should be modified.

Be sure to follow the Security Checklist.

Publish Environment publish-environment

Becoming a Member becoming-a-member

In the publish environment, depending on the settings of the community site, a site visitor may become a community member

Publish Group Roles publish-group-roles

Assigning Members to Publish Group Roles assigning-members-to-publish-group-roles

When creating a community site in the author environment, or when modifying site properties, members may be assigned various roles performed in the publish environment, such as moderators, group administrators, resource contacts, or privileged members.

Enabling the tunnel service results in assignment choices being presented from members on publish instead of users on author.

The selected members will be automatically assigned to the appropriate group and their memberships will be included when the community site is (re)published.

Privileged Members Group privileged-members-group

The purpose of a privileged members security group is to restrict the creation of content for certain community functions to a privileged subset of a community site’s members.

The privileged members group is a member group created and managed using the Communities Groups console.

After a privileged members group is created, and with the tunnel service enabled, an existing community site’s structure may be modified to edit the configuration of its community functions to ‘Allow Privileged Members’ and add the created group.

The community functions which allow specification of one or more privileged members groups are:

When a community function is not secured (no privileged members group assigned), then all community site members are allowed to create feature content (articles, events, topics, questions).

Creating Community Members creating-community-members

Repository Location repository-location

In order for certain features to work properly, it is required to create users and user groups with the appropriate privileges.

When members are created in /home/users/community, they inherit the proper ACLs that give read privileges to members’ profiles.

Similarly, custom community user groups (such as privileged members groups) should be created in /home/groups/community.

Using the Communities Members and Groups consoles will create users and groups in these paths.

To specify a custom path requires use of the classic security UI, which is accessible at https://<server>:<port>/useradmin.

To give read privileges for custom member paths, on all publish instances set ACLs similar to /home/users/community:

<allow
  jcr:primaryType="rep:GrantACE"
  rep:principalName="everyone"
  rep:privileges="{Name}[jcr:read]" >
  <rep:restrictions
    jcr:primaryType="rep:Restrictions"
    rep:glob="*/profile*" />
</allow>

To give the proper privileges for custom member group paths, such as /home/groups/mycompany, on all publish instances set ACLs similar to /home/groups/community:

<allow
  jcr:primaryType="rep:GrantACE"
  rep:principalName="community-administrators"
  rep:privileges="{Name}[jcr:read]"  />

Consoles consoles

There are four separate consoles available only in the author environment:

Community Enablement Manager Role community-enablement-manager-role

The ability for a site visitor to self register is typically not allowed for an enablement community as there are costs associated with each member. Enablement learners and resources are managed by a user assigned the role of enablement manager during site creation on author (added as member of group Community <site-name> Siteenablementmanagers). The enablement manager is also responsible for assigning learning resources to community members on author.

Only users who are members of the global Community Enablement Managers group may be selected as an enablement manager for a specific community site.

To create a user who may be assigned the role of Community Site Enablement Manager, use the classic UI security console in order to specify the path:

On an author instance:

In the left pane:

Community Administrators Role community-administrators-role

As stated in the Author Group Roles chart, members of the Community Administrators group are able to create community sites, manage sites, manage members (they can ban members from the community), and moderate content.

Follow the same steps as creating and assigning a user to the role of enablement manager, but add c ommunity-administrators group under the user’s Groups tab.

LDAP Integration ldap-integration

AEM supports the use of LDAP for authentication of users as well as creation of user accounts. This is detailed in Configuring LDAP with AEM 6.

Following are some configuration details specific for community members and member groups.

This results in users automatically being assigned to the community site’s members group and the repository location being /home/users/community and /home/groups/community, so that they inherit the appropriate permissions to see one another’s profile.

Synchronizing Users Among AEM Instances synchronizing-users-among-aem-instances

When using a publish farm, ensure users have the same path on each publish instance by importing the users first to one instance and enabling user sync to Sling distribute the users to the other publish instances.

If importing user groups, to ensure the user groups have the same path on each publish instance, import to one instance, then create a package for export, and install that package on all other publish instances.

While the syncing of user groups through user sync will be included in a future release, presently only the *membership *of a user group will sync when user sync runs.

About Community Groups about-community-groups

When discussing groups, there are two distinct topics: