search

Netcentric / accesscontroltool

Rights and roles management for AEM made easy
Eclipse Public License 1.0
150 stars 92 forks source link

Support Principal-Based Authorization #369

Open kwin opened 5 years ago

kwin commented 5 years ago

Oak 1.16 introduces principal-based authorization (OAK-8190) where the access control entries are stored in rep:PrincipalEntry nodes (https://github.com/apache/jackrabbit-oak/blob/c8e3e685ef3382f7a5053e3cec8d30569651e05a/oak-doc/src/site/markdown/security/authorization/principalbased.md#representation-in-the-repository). This allows to maintain access rights below the users rather below the nodes which are supposed to be controlled.

ghenzler commented 4 years ago

There is also some documentation around it now: https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html

kwin commented 3 years ago

This requires Jackrabbit 2.18 which only ships with AEM 6.5+ though. Also compare with Adobe-Consulting-Services/acs-aem-commons#2541. Even 6.5.13 does not come with the necessary bundle oak-authorization-principalbased so currently only AEMaaCS is supported.

AEMaaCS supports principal based authorization by default only for all users below /home/users/system/cq:services. The principal-based ACLs are persisted below the user's path in the repository.

royteeuwen commented 2 years ago

Am I correct to say that principal-based user / group configs are not supported yet by the actool? Is there any downside with AEMaaCS if you don't set it up that way that you guys know of?

kwin commented 1 year ago

According to https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2541#issuecomment-795491905 in the future principal based ACLs will be enforced by Cloud Manager for AEMaaCS. Currently service users leveraging regular ACLs trigger a warning, so the recommendation is to use repoInit with principal based ACLs for AEMaaCS (only for service users though)