[
https://issues.apache.org/jira/browse/SLING-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705872#comment-17705872
]
Angela Schreiber commented on SLING-10321:
------------------------------------------
hi [~friendlymahi], the service resource resolver/session created from the new
mapping format 'service:subservice:[servicePrincipal1, ...]' will have a java
Subject associated that only contains the specified service user principals. no
group membership is being resolved.
if you have added any of these service users to a group the permissions of
these groups will no longer be inherited upon repository login. if you
evaluated group membership manually using user management API you would still
be able to see it.... but as i mentioned i would move away from group
membership for service users and instead replace it with an aggregation of
service users such that your code can rely on effective permissions not on
group membership.
> Deprecate service mapping by userID
> -----------------------------------
>
> Key: SLING-10321
> URL: https://issues.apache.org/jira/browse/SLING-10321
> Project: Sling
> Issue Type: Improvement
> Components: Service User Mapper
> Affects Versions: Service User Mapper 1.5.2
> Reporter: Angela Schreiber
> Assignee: Angela Schreiber
> Priority: Major
> Fix For: Service User Mapper 1.5.4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> [~cziegeler], [~kpauls], for security reasons I would like to deprecate the
> old service user mapping by a single userID in favor of the new format that
> takes one or multiple principal names.
> The new format allows to keep service permissions limited to service-users as
> declared in the mapping and doesn't resolve declare or inherited group
> permissions. This gives full control over the effective permissions granted
> to each service and doesn't risk unrelated permission changes (e.g. to a base
> group like 'everyone') impacting service security.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
