Authorisation Restrictions: When are those evaluated?

[Konrad Windszus <kw...@apache.org>]

Hi,
I haven’t found any hint in https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html on when the restrictions are being evaluated.
Is it before the changes have been committed, afterwards or both?

This is particularly crucial to know for restrictions evaluating properties which are modified through a commit (e.g. a node name through Session.move(…), a property value modification via Node.setProperty(…), a primary type change via Node.setPrimaryType()).

For example is it possible to restrict writing of nodes with a particular type (irrespective of their location and parent node structure) to only a certain principal?

Thanks in advance,
Konrad

Re: Authorisation Restrictions: When are those evaluated?

[Konrad Windszus <ko...@gmx.de>]

> On 10. Jan 2023, at 12:11, Angela Schreiber <an...@adobe.com.INVALID> wrote:
> 
> hi konrad
> 
>> you cannot limit creation of a new node with a specific node type (with a node
>> type restriction ACE) nor the migration of an existing node to a certain node
>> type to certain principals only.
> 
> for changing primary type should be doable if it applies to a dedicated subtree.

How exactly?

> what i wanted to state is: if you want it to be enforced for all nodes across the whole content tree it might become tricky to manage if additional entries allowed writing in a subtree.... so, the requirement 'for a given principal certain restrictions should be applied across the whole repository content' cannot easily be reflected with the resource-based access control model afaik.
> 
> for adding nodes: note that jcr:addChildNodes privilege is evaluated on the parent and not for the node to be added. so, the restriction would need to be applied with an ACE that grants/denies adding the jcr:primaryType property which is mandatory for all nodes and thus is an indication of the add-node operation.

Granted, but as I might add the parent node of the restricted node type in the same session that does not really help here, so I can still add the node with the restricted node type, right?

> 
>> Therefore it is probably reasonable to document that it is not reasonable to use
>> property evaluating restrictions with write permissions
> 
> i wouldn't say that though. one just has to be aware that add/remove node is granted on the parent (remove also on the node itself).
> 
> kind regards
> angela
> 
> 
> ________________________________
> From: Konrad Windszus <kw...@apache.org>
> Sent: Tuesday, January 10, 2023 11:15
> To: oak-dev@jackrabbit.apache.org <oa...@jackrabbit.apache.org>
> Subject: Re: Authorisation Restrictions: When are those evaluated?
> 
> EXTERNAL: Use caution when clicking on links or opening attachments.
> 
> 
> Thanks Angela for the response and happy new year to you as well
> 
>> On 10. Jan 2023, at 10:27, Angela Schreiber <an...@adobe.com.INVALID> wrote:
>> 
>> the current restriction API does not allow to limit to/for certain principals. restrictions are not aware of the principal a given entry is evaluated for but are only aware of the path and the item the permissions applies to.
> 
> The question was more whether the item which is evaluated by the restriction in the case of write operations is the before or after state in the repository.
> 
> I guess it is just the before state, which means that you cannot limit creation of a new node with a specific node type (with a node type restriction ACE) nor the migration of an existing node to a certain node type to certain principals only.
> 
> Therefore it is probably reasonable to document that it is not reasonable to use property evaluating restrictions with write permissions, am I right?
> 
> 
> Konrad

Re: Authorisation Restrictions: When are those evaluated?

[Angela Schreiber <an...@adobe.com.INVALID>]

hi konrad

> you cannot limit creation of a new node with a specific node type (with a node
> type restriction ACE) nor the migration of an existing node to a certain node
> type to certain principals only.

for changing primary type should be doable if it applies to a dedicated subtree.
what i wanted to state is: if you want it to be enforced for all nodes across the whole content tree it might become tricky to manage if additional entries allowed writing in a subtree.... so, the requirement 'for a given principal certain restrictions should be applied across the whole repository content' cannot easily be reflected with the resource-based access control model afaik.

for adding nodes: note that jcr:addChildNodes privilege is evaluated on the parent and not for the node to be added. so, the restriction would need to be applied with an ACE that grants/denies adding the jcr:primaryType property which is mandatory for all nodes and thus is an indication of the add-node operation.

> Therefore it is probably reasonable to document that it is not reasonable to use
> property evaluating restrictions with write permissions

i wouldn't say that though. one just has to be aware that add/remove node is granted on the parent (remove also on the node itself).

kind regards
angela


________________________________
From: Konrad Windszus <kw...@apache.org>
Sent: Tuesday, January 10, 2023 11:15
To: oak-dev@jackrabbit.apache.org <oa...@jackrabbit.apache.org>
Subject: Re: Authorisation Restrictions: When are those evaluated?

EXTERNAL: Use caution when clicking on links or opening attachments.


Thanks Angela for the response and happy new year to you as well

> On 10. Jan 2023, at 10:27, Angela Schreiber <an...@adobe.com.INVALID> wrote:
>
> the current restriction API does not allow to limit to/for certain principals. restrictions are not aware of the principal a given entry is evaluated for but are only aware of the path and the item the permissions applies to.

The question was more whether the item which is evaluated by the restriction in the case of write operations is the before or after state in the repository.

I guess it is just the before state, which means that you cannot limit creation of a new node with a specific node type (with a node type restriction ACE) nor the migration of an existing node to a certain node type to certain principals only.

Therefore it is probably reasonable to document that it is not reasonable to use property evaluating restrictions with write permissions, am I right?


Konrad

Re: Authorisation Restrictions: When are those evaluated?

[Konrad Windszus <kw...@apache.org>]

Thanks Angela for the response and happy new year to you as well

> On 10. Jan 2023, at 10:27, Angela Schreiber <an...@adobe.com.INVALID> wrote:
> 
> the current restriction API does not allow to limit to/for certain principals. restrictions are not aware of the principal a given entry is evaluated for but are only aware of the path and the item the permissions applies to.

The question was more whether the item which is evaluated by the restriction in the case of write operations is the before or after state in the repository.

I guess it is just the before state, which means that you cannot limit creation of a new node with a specific node type (with a node type restriction ACE) nor the migration of an existing node to a certain node type to certain principals only.

Therefore it is probably reasonable to document that it is not reasonable to use property evaluating restrictions with write permissions, am I right?


Konrad

Re: Authorisation Restrictions: When are those evaluated?

[Angela Schreiber <an...@adobe.com.INVALID>]

hi konrad
happy new year and sorry for the delay in responding!

restrictions are part of the permission evaluation. so read operations will respect restrictions upon access of items and write operations are checked by the PermissionValidator (i.e. during commit).

there are one or two limited cases where permissions are additionally checked in the JCR layer when the check was needed for JCR compliance but not possible in oak.

the current restriction API does not allow to limit to/for certain principals. restrictions are not aware of the principal a given entry is evaluated for but are only aware of the path and the item the permissions applies to.

in other words: if you want to reliably limit/allow writing of certain nodes for a given principal i don't think it's doable with restrictions today. you could bind an ACE for a given principal and a restriction to the root node but the effect might then be overwritten by a different entry down in the hierarchy.

maybe you can elaborate a bit on the use case? maybe there is way to address this in a reliable way.

kind regards
angela


________________________________
From: Konrad Windszus <kw...@apache.org>
Sent: Wednesday, December 28, 2022 15:45
To: oak-dev@jackrabbit.apache.org <oa...@jackrabbit.apache.org>
Subject: Authorisation Restrictions: When are those evaluated?

EXTERNAL: Use caution when clicking on links or opening attachments.


Hi,
I haven’t found any hint in https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html on when the restrictions are being evaluated.
Is it before the changes have been committed, afterwards or both?

This is particularly crucial to know for restrictions evaluating properties which are modified through a commit (e.g. a node name through Session.move(…), a property value modification via Node.setProperty(…), a primary type change via Node.setPrimaryType()).

For example is it possible to restrict writing of nodes with a particular type (irrespective of their location and parent node structure) to only a certain principal?

Thanks in advance,
Konrad