Ensure Service User – An ACS AEM Commons Utility
Ensure Service User – An ACS AEM Commons Utility


Prior to AEM 6.2, developers used administrative resource resolver to access JCR programmatically. Now, Ensure Service User in AEM will make the process less error prone and easier to manage.

Problem Statement: 

Let us assume that a developer needs to access the resource from content path programmatically. Before AEM 6.2, administrative resource resolver was one of the ways to achieve the same. In addition to providing access to the content path(s), administrative resource resolver provides access to the complete repository thereby making the application prone to making undesired changes (e.g. nodes under /libs, /apps etc.). 

Since AEM 6.2, administrative resource resolver has been deprecated by Adobe and to address the above issue Adobe introduced “Service User”.  

Service User: 

A service user is a JCR user with no set password and limited privileges necessary to perform a specific task. No password requirement means that it will not be possible to login with a service user. 

JCR is accessed using service users instead of the administrative resource resolver. 

Below are two plus points about Service User. 

  • A service user per bundle with a limited set of permissions. 
  • Does not have password so no one can login. 
Problems With Service User: 
  • Manual activity on every server. 
  • Assign permission on every server. 
  • Management of these permissions is prone to error. 

Again, there is lot of manual work for developers to set up service user in different environments. 

To overcome this problem, ACS Common provides a different way to bootstrap AEM projects with different functionality, a set of reusable components and AEM development kit.  

Here, we are going to discuss great utilities of ACS common named “Ensure Service User”.  


Ensure Authorizable or Ensure Service User: 

Ensure Service User is provided by ACS commons. Here is some points about Ensure Service User. 

  • Create once and use everywhere. 
  • Define service user and their ACL in OSGi configuration. 
  • Less error prone and easy to maintain. 
  • You can manage the group and hierarchies for service user. 
  • Available since version v3.8.0. 


How to use: 

Here step by step procedure are described to use “Ensure Service User”. 

  1. Create an OSGi configuration for service user using factory configuration 


<?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling="" xmlns:cq=""   xmlns:jcr="" xmlns:nt=""   jcr:primaryType="sling:OsgiConfig"   principalName="meetup-service-user"   type="add"   ensure-immediately="{Boolean}true"   aces="[type=allow;privileges=jcr:read\,rep:write;path=/content]"/> 

Here please note followings points: 

Principal Name: 

Principal name is name of your service user. It can be just principal name or principal name with relative path or principal name with absolute path.  

Remember, service users may only exit under /home/users/system” path. 

For example: 

     1. Your Inputmeetup-service-user  

Service User will be created under path: “/home/users/system/meetup-service-user” 

     2. Your Input: /my-company/meetup-service-user or my-company/meetup-service-user or /my-company/meetup-service-user 

Service User will be created under path: “/home/users/system/my-company/meetup-service-user” 

     3. Your Input: /home/users/system/my-company/meetup-service-user 

Service User will be created under path: “/home/users/system/my-company/meetup-service-user” 


  • If a system user exists with the same principal name at a DIFFERENT location, this tool assumes that service user is correct and not attempt to move it to the specified location in this configuration. 
  • If a principal name is specified for an AEM or ACS AEM Commons provided system user, the ensure user process will fail. This list may not always be exhaustive and up to date and meant to help protect against collisions. 

ACS AEM Commons provide the facility to add or remove Service User. Here we are creating the service user. 

Option “add”: Ensure the existence of service user. 

Option “remove”: Ensure that service user is removed. 


Two options are available, we can set it either true or false. By default, it is true. 

Option “true”: When set to true, the insurance is performed whenever this bundle is loaded. 


Aces:  Array of ACE (access control entry) definitions to ensure for the principal. 

Format: type=allow;privileges=jcr:read,rep:write;path=/content/foo;rep:glob=/jcr:content/* 

  • type: allow OR deny, it is required property. 
  • privileges: comma delimited list of valid JCR privileges, it is required property. 
  • path: absolute content path which the ACE will be applied, it is required property.


     1. Service user mapping with OSGi Service. 

Map your service user with Resource resolver service. 

<?xml version="1.0" encoding="UTF-8"?><jcr:root xmlns:sling="" xmlns:jcr=""  jcr:primaryType="sling:OsgiConfig"  user.mapping="[com.argildx.argildx-meetup:ResourceResolverUtil=meetup-service-user]"/> 
     2. Use this service to get resource resolver instance. 
public class ResourceResolverUtil { 

  /** The resource resolver factory. */   

@Reference private transient ResourceResolverFactory resourceResolverFactory; 

  /** Gets the resource resolver. 

   * @return the resource resolver  */ 

public ResourceResolver getResourceResolver() { 

    ResourceResolver resourceResolver = null; 

    try {      final Map<String, Object> authInfo = Collections.singletonMap(ResourceResolverFactory.SUBSERVICE, (Object) "ResourceResolverUtil");       

resourceResolver = resourceResolverFactory.getServiceResourceResolver(authInfo);     

} catch (LoginException le) { 


return resourceResolver;   



A working demo present on bitbucket can be viewed on the following  link: 

Share it:

Argil DX Media

April 18, 2019

Leave a Comment

Related Posts