You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Angela Schreiber (Jira)" <ji...@apache.org> on 2021/01/19 15:31:00 UTC

[jira] [Updated] (SLING-10070) Option to enforce principal-based authorization

     [ https://issues.apache.org/jira/browse/SLING-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Angela Schreiber updated SLING-10070:
-------------------------------------
    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]}} 

  was:
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, built-in-with-principal-based-authorization}}  -> 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]}} 


> Option to enforce principal-based authorization
> -----------------------------------------------
>
>                 Key: SLING-10070
>                 URL: https://issues.apache.org/jira/browse/SLING-10070
>             Project: Sling
>          Issue Type: New Feature
>          Components: Content-Package to Feature Model Converter
>            Reporter: Angela Schreiber
>            Priority: Major
>
> 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]}} 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)