To access the data storage in the Resource Tree and/or the JCR Repository authentication is required to properly setup access control and guard sensitive data from unauthorized access. For regular request processing this authentication step is handled by the Sling Authentication subsystem.
On the other hand there are also some background tasks to be executed with access to the resources. Such tasks cannot in general be configured with user names and passwords: Neither hard coding the passwords in the code nor having the passwords in – more or less – plain text in some configuration is considered good practice.
To solve this problem for services to identify themselves and authenticate with special users properly configured to support those services.
The solution presented here serves the following goals:
- Prevent over-use and abuse of administrative ResourceResolvers and/ro JCR Sessions
- Allow services access to ResourceResolvers and/or JCR Sessions without requiring to hard-code or configure passwords
- Allow services to use service users which have been specially configured for service level access (as is usually done on unixish systems)
- Allow administrators to configure the assignment of service users to services
A Service is a piece or collection of functionality. Examples of services are the Sling queuing system, Tenant Administration, or some Message Transfer System. Each service is identified by a unique Service Name. Since a service will be implemented in an OSGi bundle (or a collection of OSGi bundles), services are named by the bundles providing them.
A Service may be comprised of multiple parts, so each part of the service may be further identified by a Subservice Name. This Subservice Name is optional, though. Examples of Subservice Name are names for subsystems in a Message Transfer System such as accepting messages, queueing messages, delivering messages.
Ultimately, the combination of the Service Name and Subservice Name defines the Service ID. It is the Service ID which is finally mapped to a Resource Resolver and/or JCR Repository user ID for authentication.
Thus the actual service identification (service ID) is defined as:
service-id = service-name [ ":" subservice-name ] .
service-name is the symbolic name of the bundle providing the service.
Example: Tenant Administration¶
Tenant Administration mostly deals with creating and managing groups
and some other user administration tasks. Instead of just using an
administrative session for Tenant administration this feature could
define itself as being the
tenant-admin service and leverage a
properly configured Tenant Administration account.
Example: Mail Transfer System¶
Consider a Mail Transfer System which may be comprised of the following sub systems:
- Accepting mail for processing — for example the SMTP server daemon
- Queing and processing the messages
- Delivering messages to mailboxes
You could conceive that all these functions serve different purposes and thus should have different access rights to the repository to persist messages while they are being processed.
Using the Service Authentication framework, the Mail Transfer System
would be consituting the
mta service. The sub systems would be called
Thus the SMTP server daemon would be represented by a user for the
mta:smtp Service. queueing with
mta:queue, and delivery with
The implementation in Sling of the Service Authentication concept described above consists of three parts:
The first part is a new OSGi Service
ServiceUserMapper service allows for mapping Service IDs comprised of
the Service Names defined by the providing bundles and optional Subservice Name
to ResourceResolver and/or JCR Repository user IDs. This mapping is configurable
such that system administrators are in full control of assigning users to services.
ServiceUserMapper defines the following API:
String getServiceUserID(Bundle bundle, String subServiceName);
The second part is support for service access to the Resource Tree. To this
ResourceResolverFactory service is enhanced with a new factory
ResourceResolver getServiceResourceResolver(Map<String, Object> authenticationInfo) throws LoginException;
This method allows for access to the resource tree for services where the
service bundle is the bundle actually using the
service. The optional Subservice Name may be provided as an entry
In addition to having new API on the
ResourceResolverFactory service to
be used by services, the
ResourceProviderFactory service is updated
with support for Service Authentication: Now new API is required, though
but additional properties are defined to convey the service to authenticate
The third part is an extension to the
to support JCR Repository access for services:
Session loginService(String subServiceName, String workspace) throws LoginException, RepositoryException;
This method allows for access to the JCR Repository for services where the
service bundle is the bundle actually using the
service. The additional Subservice Name may be provided with the
Deprecation of administrative authentication¶
SlingRepository.loginAdministrative methods have been defined to
provide access to the resource tree and JCR Repository. These methods
proved to be inappropriate because they allow for much too broad access.
Consequently these methods are being deprecated and will be removed in future releases of the service implementations.
The following methods are deprecated:
The implementations we have in Sling's bundle will remain implemented
in the near future. But there will be a configuration switch to disable
support for these methods: If the method is disabled, a
is always thrown from these methods. The JavaDoc of the methods is
extended with this information.