You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (Jira)" <ji...@apache.org> on 2019/12/18 12:44:00 UTC

[jira] [Closed] (JCR-3716) Inconsistent Principal Validation between API and Import behavior

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

Julian Reschke closed JCR-3716.
-------------------------------

> Inconsistent Principal Validation between API and Import behavior
> -----------------------------------------------------------------
>
>                 Key: JCR-3716
>                 URL: https://issues.apache.org/jira/browse/JCR-3716
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.7.3
>            Reporter: Tobias Bocanegra
>            Assignee: Tobias Bocanegra
>            Priority: Minor
>
> the JCR access control management mandates that adding a new ACE includes validating if the specified principal is known to the repository.
> however, the ac-importer in jackrabbit is more relaxed wrt that validation and allows to create ACE even for unknown principals. this basically leaves us with an inconsistent behavior between xml-import and calls to ac-management API directly.
> also note, that principal validation is only done when applying and ACL but not when removing a principal. 
> in order to fix that i would suggest the following approach:
> - add a new configuration parameter to the ACLProvider: "allow-unknown-principals"
> - make the import behavior independent of the principal manager
> - respect this configuration when checking the ACL templates
> this will change the default behavior of the XML import of access controlled content. if this is a problem for backward compatibility, we can additionally add a "importBehavior" property to the ACL importer that has a "besteffort" mode where the principals check is bypassed (as in the current implementation)



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