search

AdobeDocs / experience-manager-cloud-service.en

This is the repository for Adobe Experience Manager as a Cloud Service documentation. Your contributions to the documentation are welcome.
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service
MIT License
3 stars 41 forks source link

Principal-based authentication is not supported in AEM 6.4/6.5 #192

Closed kwin closed 3 months ago

kwin commented 3 months ago

Issue in ./help/security/best-practices-for-sling-service-user-mapping-and-service-user-definition.md

The best practice

The new format with [one,or,multiple,principalNames] is the recommended way to define service user mappings as of AEM 6.4.

is wrong, as AEM 6.4 and AEM 6.5 (even with SP21) don't ship with the necessary oak-authorization-principalbased bundle (compare with https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2541#issuecomment-1154902821)

aheim0 commented 3 months ago

Thanks for raising this - we will investigate.

aheim0 commented 3 months ago

@adobe export issue to Jira project CQDOC

github-jira-sync-bot commented 3 months ago

:white_check_mark: Jira issue CQDOC-21695 is successfully created for this GitHub issue.

aheim0 commented 3 months ago

@kwin

We've checked with RnD and have had the following response:

"the new service user mapping format doesn't require principal-based authorization in order to work. principal-based authorization is just the recommended way to setup permissions for service users.... but has nothing to do with the Sling service user mapping. the latter defines how the service login is performed, not how authorization is done."

Hope that helps, and closing this issue.

kwin commented 3 months ago

That makes a lot of sense. Thanks a lot for the answer and sorry for the noise.

aheim0 commented 3 months ago

@kwin Absolutely no problem!

aheim0 commented 3 months ago

@kwin Hello again - we've just had some further information from RnD:

"Sling Service User Mapping and Authentication

the main difference between the deprecated format and the new format is that the latter allows to aggregate multiple service user principals. the resulting subject upon login (both for service session and service resource resolver) contains a set of principals that contains exactly the principals specified in the service user mapping. the first one being used to populate the user id field. there will be no group membership resolution as we don't want service users to be place into groups. service users are part of the application content, while groups are not. permission setup for services (and thus the service users) are part of the development process (thus application) and must not be impacted by changes to permission setup for groups (in particular everyone group).

Access Control Setup for Service Users

Ideally ac setup for service users is principal-based as it would allow us to make it immutable like content below /apps and /libs. That's why service users that support principal-based authorization are place into a dedicated configured subtree.

However, for service users outside of that subtree regular resource-based access control setup can be used."

Again, hope that helps (further).