Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
while addressing SLING-9692 an configuration for enforcing principal-based authorization upon content package conversion was introduced. however, karlpauls and myself discussed the impact of the forced migration and found that some additional verification might be needed:
in the following cases the forced conversion to principal-based is needed
- service-mapping in the format bundle.subservice=[userfromcontentpackage, built-in-with-principal-based-authorization] will require the userfromcontentpackage to be installed with prinicipal-based ac setup if the built-in user no longer has resource-based ac setup defined
in the following case however it is not desirable
- service-mapping in the format bundle.subservice=userfromcontentpackage -> service login will resolve group membership (group principals not supported by principal-based authorization. see oak documentation and exercises for details)
in the following cases it is not required but is likely beneficial given that ultimately all service user permissions should be defined with principal-based access control setup
- service-mapping in the format bundle.subservice=[userfromcontentpackage]
- service-mapping in the format bundle.subservice=[userfromcontentpackage, anotheruserfromcontentpackage]
Attachments
Issue Links
- depends upon
-
SLING-9692 Add support for principal-based access control entries
-
- Closed
-
- fixes
-
SLING-9982 ConfigurationEntryHandlerTest: doesn't test serviceusermapping with principalname-array
-
- Closed
-
- relates to
-
SLING-10210 Option to enforce service-user-mapping with principal names
-
- Closed
-
- links to