[
https://issues.apache.org/jira/browse/OAK-8155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803817#comment-16803817
]
angela edited comment on OAK-8155 at 3/28/19 12:18 PM:
-------------------------------------------------------
[~stillalex], imagine the following composite authorization setup aggregated
with {{CompositionType.AND}}:
# CugAuthorization configured to be supported at _/content_
# CustomAuthorizationConfiguration grant-only module for all type of
privileges, which is limited to be be evaluated for items below _/content_ and
a specific type of {{Principal}} only, let's take e.g. SystemUserPrincipal. for
any other paths/principal permission evalution of this module would be skipped
(i.e. {{PermissionProvider.EMPTY}} will be returned.
# AuthorizationConfigurationImpl (the default)
Since the default implementation {{AuthorizationConfigurationImpl}} takes
effect everywhere and respects all principals, it won't be sufficient to grant
my special principal access with {{CustomAuthorizationConfiguration}}, but also
would need to grant the same permission with the default model. while an OR
setup would do the trick if it was just my custom model and the default, this
doesn't meet my needs, when I additional want to be able to place CUGs at
/content and have read-access revoked.
In other words: If you take any regular user session on one hand and a special
session as a second case accessing _/content/a/b/cug/node_ i would envision the
following flow:
# Regular User (no special principal in the subject)
#
## CugPermissionProvider.isGranted("/content/a/b/c/node", READ)
=> if false (i.e.within a cug the user has no access) abort and return
{color:#f79232}DENY{color}
=> if true (i.e. within a cug and the user has access) continue evaluating
## PermissionProvider.EMPTY -> ignored
## PermissionProviderImpl.isGranted("/content/a/b/c/node", READ)
=> if false => return {color:#f79232}DENY{color}
=> if true => return {color:#8eb021}ALLOW
{color}
# {color:#333333}Special User (e.g. just {{SystemUserPrincipal}}){color}
## CugPermissionProvider.isGranted("/content/a/b/c/node", READ)
=> if false (i.e.within a cug the user has no access) abort and return
{color:#f79232}DENY{color}
=> if true (i.e. within a cug and the user has access) continue evaluating
## CustomPermissionProvider.isGranted("/content/a/b/c/node", READ)
=> if false abort and return {color:#f79232}DENY{color}{color:#f79232}
{color:#333333}=> if true abort and return
{color}{color}{color:#8eb021}ALLOW{color}
The way it works today the second scenario would ways continue evaluating with
the PermissionProviderImpl.... does that help illustrating what I am looking
for?
was (Author: anchela):
[~stillalex], imagine the following composite authorization setup aggregated
with {{CompositionType.AND}}:
# CugAuthorization configured to be supported at _/content_
# CustomAuthorizationConfiguration grant-only module for all type of
privileges, which is limited to be be evaluated for items below _/content_ and
a specific type of {{Principal}} only, let's take e.g. SystemUserPrincipal. for
any other paths/principal permission evalution of this module would be skipped
(i.e. {{PermissionProvider.EMPTY}} will be returned.
# AuthorizationConfigurationImpl (the default)
Since the default implementation {{AuthorizationConfigurationImpl}} takes
effect everywhere and respects all principals, it won't be sufficient to grant
my special principal access with {{CustomAuthorizationConfiguration}}, but also
would need to grant the same permission with the default model. while an OR
setup would do the trick if it was just my custom model and the default, this
doesn't meet my needs, when I additional want to be able to place CUGs at
/content and have read-access revoked.
In other words: If you take any regular user session on one hand and a special
session as a second case accessing _/content/a/b/cug/node_ i would envision the
following flow:
# Regular User (no special principal in the subject)
## CugPermissionProvider.isGranted("/content/a/b/c/node", READ)
=> if false (i.e.within a cug the user has no access) abort and return
{color:#f79232}DENY{color}
=> if true (i.e. within a cug and the user has access) continue evaluating
## PermissionProvider.EMPTY -> ignored
## PermissionProviderImpl.isGranted("/content/a/b/c/node", READ)
=> if false => return {color:#f79232}DENY{color}
=> if true => return {color:#8eb021}ALLOW
{color}
# {color:#333333}Special User (e.g. just {{SystemUserPrincipal}}){color}
## CugPermissionProvider.isGranted("/content/a/b/c/node", READ)
=> if false (i.e.within a cug the user has no access) abort and return
{color:#f79232}DENY{color}
=> if true (i.e. within a cug and the user has access) continue evaluating
## CustomPermissionProvider.isGranted("/content/a/b/c/node", READ)
=> if false abort and return {color:#f79232}DENY{color}{color:#f79232}
{color:#333333}=> if true abort and return
{color}{color:#8eb021}ALLOW{color}{color}
{color:#f79232}{color:#8eb021}{color:#333333}The way it works today the second
scenario would ways continue evaluating with the PermissionProviderImpl....
does that help illustrating what I am looking for?{color}{color}{color}
> CompositePermissionProvider: add possibility to abort evaluation
> ----------------------------------------------------------------
>
> Key: OAK-8155
> URL: https://issues.apache.org/jira/browse/OAK-8155
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security, security-spi
> Reporter: angela
> Assignee: angela
> Priority: Major
> Fix For: 1.12.0
>
>
> when aggregating multiple authorization models we currently have the ability
> to choose between CompositionType.AND and CompositionType.OR for the
> evaluation of effective permissions. In other words as soon as more than 1
> PermissionProvider is present for the evaluation the results of that
> evaluation are either combined in an AND or OR fashion.
> however, we currently lack the ability to stop or abort the evaluation if a
> given provider instance was 'sufficient' to determine if a given set of
> permissions is granted or denied.
> [~stillalex], let's discuss ideas and options on how we could achieve this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
