[
https://issues.apache.org/jira/browse/SLING-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14363013#comment-14363013
]
Felix Meschberger edited comment on SLING-4461 at 3/16/15 10:12 AM:
Service User Mapping has been introduced as a security feature to allow
(background) services to operate in a least privileges required way instead of
granting them all full repository access through
getAdministrativeResourceResolver and loginAdministrative.
The defaults have been introduced as a convenience measure allowing to migrate
code towards service user mapping.
Now the the ServiceUserMapping service introduced with SLING-4312 enforces a
stricter approach. From a security point of view, this is actually better,
since this makes sure a component is only enabled if the expected service user
mapping is actually exactly given as required.
As such the ServiceUserMapping service dependency narrows the functionality
towards the more secure angle.
Should we thus drop the defaults because ServiceUserMapping dependency and
defaults fallback support are not equivalent from an API point of view ? Sounds
like throwing out the baby with the bath water.
Using filters we have a number of options, actually:
* @Reference(mapping.target=(subServiceName=dedicatedUserService))
Require mapping for the given sub service name
* @Reference(mapping.target=(!(subServiceName=*)))
Require a plain service name mapping
*
@Reference(mapping.target=(|(subServiceName=dedicatedUserService)(!(subServiceName=*
Ask for sub service name mapping, allowing fallback to plain service name
mapping
The question is just how we would handle allowing a falling back to the default
user mapping. Maybe we define a new service property {{default}} which is only
set for the default mapping ?
So, with filters we can cover everything from most narrow requirements to
broadest possible openness as supported by the API.
Whether we define an annotation to simplify the initial setup or not is another
question.
Last but not least: The fall back defaults are not really less deterministic
than not having them. For one thing the fall-back mechanism fully determined:
# If a subservice name is required check that mapping first
# Then go for service name only mapping
# Then fall back to default mapping (if configured)
The non-determinism comes from the the fact, that configuration may be updated
at any time. But this is a fundamental tenet of the OSGi framework and as such
is not really a problem. In fact having the ServiceUserMapped service allows to
actually cope with this dynamism in that a component may be taken out of
service if a mapping is removed.
was (Author: fmeschbe):
Service User Mapping has been introduced as a security feature to allow
(background) services to operate in a least privileges required way instead of
granting them all full repository access through
getAdministrativeResourceResolver and loginAdministrative.
The defaults have been introduced as a convenience measure allowing to migrate
code towards service user mapping.
Now the the ServiceUserMapping service introduced with SLING-4312 enforces a
stricter approach. From a security point of view, this is actually better,
since this makes sure a component is only enabled if the expected service user
mapping is actually exactly given as required.
As such the ServiceUserMapping service dependency narrows the functionality
towards the more secure angle.
Should we thus drop the defaults because ServiceUserMapping dependency and
defaults fallback support are not equivalent from an API point of view ? Sounds
like throwing out the baby with the bath water.
Using filters we have a number of options, actually:
* @Reference(mapping.target=(subServiceName=dedicatedUserService))
Require mapping for the given sub service name
* @Reference(mapping.target=(!(subServiceName=*)))
Require a plain service name mapping
*
@Reference(mapping.target=(|(subServiceName=dedicatedUserService)(!(subServiceName=*
Ask for sub service name mapping, allowing fallback to plain service name
mapping
The question is just how we would handle allowing a falling back to the default
user mapping. Maybe we define a new service property {{default}} which is only
set for the default mapping ?
Whether we define an annotation to simplify the initial setup or not is another
question.
Remove fallbacks for service users resolution
-
Key: SLING-4461
URL: https://issues.apache.org/jira/browse/SLING-4461
Project: Sling
Issue Type: Improvement
Components: Service User Mapper
Reporter: Marius Petria
ServiceUserMapperImpl has several levels of fallback for service user
resolution (fallback to bundle default, or to global default).
