[jira] [Commented] (SLING-6963) Service user declaration based on principal names

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (SLING-6963) Service user declaration based on principal names

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050578#comment-16050578 ]

Felix Meschberger commented on SLING-6963:

Thanks, [~anchela]. I quickly reviewed the patch. Basically I like this idea very much.

There are a few comments, though:

* As [~cziegeler] indicated, please refrain from adding the Guava library as a dependency to the ServiceUserMapper (unfortunately, this seems to already have been made in the jcr.base bundle :-(
* There is a change in semantics in an internal/private method. While it has no consequences, I would prefer to not have it (see respective two comments on the isValidUser and areValidPrincipals methods)
* I would prefer to not enforce an increased version dependency on the ServiceUserMapper service in the jcr.base bundle. Rather I would suggest to keep the dependency low and check whether the getServicePrincipalNames method is available on the ServiceUserMapper service bound.

> Service user declaration based on principal names
> -------------------------------------------------
>                 Key: SLING-6963
>                 URL: https://issues.apache.org/jira/browse/SLING-6963
>             Project: Sling
>          Issue Type: Improvement
>          Components: JCR, Service User Mapper
>            Reporter: angela
> Currently {{SlingRepository.loginService}} relies on a configuration that maps services/subservices to a single service user by it's name/ID. Heavy usage of this concept over the last years has reveal a couple of findings, we missed when inventing the service user concept:
> - it is prone to redundant of permission setup when defining permissions for individual service users that often share common needs while at the same time being responsible for completing distinct special operations (e.g. _read-content_ (common) and _write-special-subtree_ (special operation)
> - some services require a combination of different operations reflected by existing groups and we ended up having service users being put into groups in order to avoid permission duplication (ultimately leaving us with somewhat intransparent permission setup for a given service).
> Learning from these findings I like would proposed an alternative way of registering service users that would allow for specifying a set of principal names, effectively declaring all tasks a given service is designed to complete. this would allow to re-use existing service users and thus avoid duplication of permission setup for both cases mentioned above.
> Also, implementing this alternative mapping would allow to get rid of the double repository login as it is currently present within {{AbstractSlingRepository2#createServiceSession}} and as such have a positive impact on performance.

This message was sent by Atlassian JIRA