Users/Groups

Last updated on 30th September, 2017 by George Taylor

Users

While users in AEM apps should not generally be deployed with the application, to build an application that modifies content via the code we should use a system user to access the content, and allow the correct access.

Users in AEM, while they appear in the jcr:content, they are not handled like normal nodes.

A System users node is in /home/users/system I do then tend to create an application folder for the users.

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:rep="internal"
jcr:primaryType="rep:SystemUser"
jcr:uuid="ebe5f4d0-2869-331a-ac51-8a70c909de7a"
rep:authorizableId="sample-service-user"
rep:principalName="sample-service-user"/>

As you can see the user node is pretty basic, however there are a few bits of important information

  • rep:authorizableId
    • The id that you would lookup the user in the authorisation api
  • rep:principalName
    • The principal name
    • Should be the same as the authorizableId
  • jcr:primaryType
    • Defines that the user is a system user
  • jcr:uuid
    • The unique id for the user
    • Can't be created manually

To create a system user you have to go into CRX Explorer (/crx/explorer/index.jsp)

  • Click User Administration which will popup a new window.
  • Click Create System user and fill in the user id and the path you want the system user to be placed
  • I will then create a package and export the user into my code base so i can deploy it with my code
  • You can configure your system user to be available to your code in the ui.apps configuration for the service user mapper
    • org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<app>
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
jcr:primaryType="sling:OsgiConfig"
service.ranking="{Decimal}0"
user.mapping="[sample.core:service=sample-service-user]"/>

You can create as many service users with different names as you like, the user mapping needs to be you java's package followed by the service name. I always create a service user, but sometimes i create multiple that will have access to different areas of the jcr:repository for different purposes. i.e. a workflow user, an activation user e.t.c

While you can create users in AEM and export them with your application, this is a very bad practice. I have created packages with users in the past for test users and deployed them on the test servers, but all end users should be created manually in production systems.

Groups

Groups should also be created manually using the useradmin screen, once created they can be exported in the same way. All groups are stored in /home/groups and again I tend to create a sub folder for storing my applications groups so that they are easy to find.

Groups will always come with more than one file when it is exported, the main .content.xml file will be

<?xml version= "1.0" encoding= "UTF-8" ?>
<jcr:root xmlns:sling= "http://sling.apache.org/jcr/sling/1.0" xmlns:cq= "http://www.day.com/jcr/cq/1.0" xmlns:jcr= "http://www.jcp.org/jcr/1.0" xmlns:nt= "http://www.jcp.org/jcr/nt/1.0" xmlns:rep= "internal"
cq:lastModified= "{Date}2017-05-23T08:28:52.315Z"
cq:lastModifiedBy= "admin"
jcr:mixinTypes= "[rep:AccessControllable]"
jcr:primaryType= "rep:Group"
jcr:uuid= "e67c99a7-bbbd-3ae5-8cce-10f837eb29e2"
rep:authorizableId= "sample_acl"
rep:members= "{WeakReference}[2b792a03-6c6e-3c4c-b465-c8d128d102cb]"
rep:principalName= "sample_acl" >
<profile
jcr:primaryType= "nt:unstructured"
sling:resourceType= "cq/security/components/profile"
aboutMe= "Allow an author to set ACL settings"
givenName= "Sample ACL" />
</jcr:root>

Most of the data is very similar to the users data, however you have a few extra pieces

  • rep:members
    • This is a list of the members that are part of the group
    • Should not be exported in your code as the reference may not exist in your instance of AEM
    • Can be left if it refers to another group that is also being deployed at the same time
  • profile
    • Group profiles are not mandatory but give additional information about the group
    • aboutMe
      • The description of the group
    • givenName
      • The name of the group

If you go into useradmin and look at a user you will see that they can be part of many groups. The UI actually hides that the user has no reference to the group, but instead the group has a reference to the user, or other groups that are extending the rights of this group.