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 the 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 log in 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.
It does not have a password so no one can log in.
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 a lot of manual work for developers to set up service users 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 an 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 are 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 the service users.
Available since version v3.8.0.
How to use:
Here step by step procedures are described to use “Ensure Service User”.
Create an OSGi configuration for service user using factory configuration
com.adobe.acs.commons.users.impl.EnsureServiceUser-meetupUser.xml
<?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" 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:
The principal name is the name of your service user. It can be just a principal name or principal name with a relative path or principal name with an absolute path.
Remember, service users may only exist under the “/home/users/system” path.
For example:
1. Your Input: meetup-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”
Note:
If a system user exists with the same principal name at a DIFFERENT location, this tool assumes that the 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.
Type:
ACS AEM Commons provides the facility to add or remove Service Users. Here we are creating the service user.
Option “add”: Ensure the existence of service users.
Option “remove”: Ensure that service user is removed.
Ensure-Immediately:
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 a required property.
privileges: comma-delimited list of valid JCR privileges, it is a required property.
path: an absolute content path in which the ACE will be applied, it is a required property.
1. Service user mapping with OSGi Service.
Map your service user with Resource resolver service.
org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-meetupUser.xml
<?xml version="1.0" encoding="UTF-8"?><jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" jcr:primaryType="sling:OsgiConfig" user.mapping="[com.argildx.argildx-meetup:ResourceResolverUtil=meetup-service-user]"/>
2. Use this service to get a 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;
}}
Demo:
A working demo present on bitbucket can be viewed on the following link: https://bitbucket.org/argildx/aemdev-meetup-s1/overview
No comments:
Post a Comment
If you have any doubts or questions, please let us know.