[jira] [Commented] (SLING-10321) Deprecate service mapping by userID

["Mahidhar Chaluvadi (Jira)" <ji...@apache.org>]

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

Mahidhar Chaluvadi commented on SLING-10321:
--------------------------------------------

[~angela] - Hello I have a question. Reading the documentation I understand the permissions managed via grp membership are not effective for service users when mapping via principal instead of user id. But does this mean the group memberships are gone when trying to perform API calls that depend on group membership? For e.g. We use a custom API that does UserManager operations, and requires that service user is part of user-administrators, else causes AccessDenied regardless of what permissions we grant on respective folders. In future I hope removal of user-id based mapping being gone shouldn't impact this functionality. Please confirm the same.

 

cc: [~sseifert] 

> 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)