Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
IMHO, AclUtil.setAcl makes the following invalid assumptions about principals:
- every principal is backed by a user/group defined by jackrabbit user management (which already is not necessarily true for the everyone group, which was probably the reason for the extra if for everyone)
- for those cases where a given principal is in fact associated with an known user/group, the implementation assumes that the principal name is identical to the ID
for the former it is sufficient to look at the everyone principal or at the synchronization mechanism in oak-auth-external, which defines an additional PrincipalProvider that does not require principals to be reflected as users/goups and for which setting up access control content is equally valid (see also oak-exercise module for a simplistic, custom principal provider to play around with).
the latter can easily be illustrated by creating a user/group account with a different principal name by calling UserManager.createUser(String, String, Principal, String) or UserManager.createGroup(String, Principal, String.
Attachments
Attachments
Issue Links
- is required by
-
SLING-8605 AclUtil.createLocalRestrictions should use JackrabbitAccessControlList.isMultiValueRestriction(String)
- Closed
- relates to
-
SLING-8602 Add support for PrincipalAccessControlList and ac-management by principal
- Closed