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:
-
Create sub-communities within the community site (see community groups).
-
Moderate user generated content (UGC).
-
Be privileged to create entries for blogs, calendars, QnA, and forums.
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
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 " Engage", then one of the user groups created would be:
- Community Engage Members
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.
- For details, see configuration instructions on the deployment page.
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:
-
When the community site is private (closed):
- By invitation
- By actions of an administrator
-
When the community site is public (open):
- By self-registration
- By social login with Facebook and Twitter
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鈥檚 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鈥檚 structure may be modified to edit the configuration of its community functions to 鈥楢llow Privileged Members鈥 and add the created group.
The community functions which allow specification of one or more privileged members groups are:
- Blog function - To restrict creation of new articles.
- Calendar function - To restrict creation of new events.
- Forum function - To restrict creation of new topics.
- QnA function - To restrict creation of new questions.
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 .
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 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鈥檚 Groups tab.
LDAP Integration ldap-integration
AEM supports the use of LDAP for authentication of users and 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.
-
Configure LDAP for each AEM publish instance.
-
- No special instructions
-
-
Set the following properties:
- User auto membership:
community-<site name>-<uid>-members
- User Path Prefix:
/community
- Group Path Prefix:
/community
- User auto membership:
-
-
- no special instructions
This results in users automatically being assigned to the community site鈥檚 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鈥檚 profile.
- The
User auto membership
value should be therep:authorizableId
property, not thegivenName
(display name) from the 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:
-
Community groups are the sub-communities which may be created in the publish environment for a community site which supports creation of community groups. Creation of a community group results in more pages added to the website and are managed in a manner similar to their parent community site. For more information visit Community Group Essentials for developers and Community Group for authors.
-
Member groups are the groups to which members may belong and are managed through the Groups console. Much of the discussion on this page has been devoted to member groups. The member groups automatically created for a community site, which are prefixed with
Community
, may be referred to as a community group, therefore the context of the discussion must be considered.