[jira] [Updated] (SLING-6963) Service user declaration based on principal names
[
https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-6963:
---
Labels: Sling-10-ReleaseNotes (was: )
> 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: Service User Mapper
>Reporter: angela
>Assignee: Karl Pauls
> Labels: Sling-10-ReleaseNotes
> Fix For: Service User Mapper 1.3.4
>
> Attachments: SLING-6963-with-tests.patch
>
>
> 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)
[jira] [Updated] (SLING-6963) Service user declaration based on principal names
[
https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-6963:
Fix Version/s: Service User Mapper 1.3.4
> 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: Service User Mapper
>Reporter: angela
> Fix For: Service User Mapper 1.3.4
>
> Attachments: SLING-6963-with-tests.patch
>
>
> 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)
[jira] [Updated] (SLING-6963) Service user declaration based on principal names
[
https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated SLING-6963:
--
Attachment: (was: SLING-6963.patch)
> 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: Service User Mapper
>Reporter: angela
> Attachments: SLING-6963-with-tests.patch
>
>
> 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)
[jira] [Updated] (SLING-6963) Service user declaration based on principal names
[
https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated SLING-6963:
--
Attachment: SLING-6963-with-tests.patch
> 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: Service User Mapper
>Reporter: angela
> Attachments: SLING-6963-with-tests.patch
>
>
> 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)
[jira] [Updated] (SLING-6963) Service user declaration based on principal names
[
https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated SLING-6963:
--
Attachment: SLING-6963.patch
proposed patch incorporating initial review findings. more tests will follow
soon.
> 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: Service User Mapper
>Reporter: angela
> Attachments: SLING-6963.patch
>
>
> 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)
[jira] [Updated] (SLING-6963) Service user declaration based on principal names
[
https://issues.apache.org/jira/browse/SLING-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated SLING-6963:
--
Component/s: (was: JCR)
> 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: 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)
[jira] [Updated] (SLING-6963) Service user declaration based on principal names
[
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)
