[ https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated SLING-6963: -------------------------- Summary: Service user declaration based on principal names (was: Service user declaration based on a set of principal names) > 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 (v6.4.14#64029)