You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Markus Joschko <ma...@gmail.com> on 2011/10/10 23:02:32 UTC
Conditional access control
Hi,
In my repository I have a structure that has many deep branches.
Within these branches there are three different types of nodes.
Each type is maintained by another group of users. These groups can be
configured per branch
(it's a bit like in a file system where one group can only maintain
the folders and the other group only the files in a branch).
Now the question is how to best handle the access control here.
I can:
- either add an ace to each and every node in the repository and pay
the price that I have to maintain a lot of them in case ownership of a
branch changes or subbranches are moved into different branches.
- find a way to hook into the accesscontrol mechanism of jackrabbit to
make this easier. So far I have failed to find a good way to do so.
I initially thought about introducing custom privileges that can be
used as markers and then extend the ACLProvider to take these
privileges also into account when calculating permissions.
However from looking at the code it seems to me, that custom
privileges can only be defined as aggregates of existing privileges
and then also the aggregate can not exist twice. I guess it is not a
good
idea to create artificial aggregates just to define new privileges.
- an alternative might be to create new accesscontrol entries that do
not only have path restrictions but also nodetype restrictions.
However that seems to be quite invasive and a lot of work.
Any other ideas how to tackle that problem?
- Markus
Re: Conditional access control
Posted by Markus Joschko <ma...@gmail.com>.
On Tue, Oct 11, 2011 at 6:01 PM, Mark Herman <MH...@nbme.org> wrote:
>
> Markus Joschko wrote:
>>
>> Guess I still miss a piece.
>> How do I prevent somebody with write/delete/modify rights to Suisse to
>> also modify the Entity1b node?
>> The only node I can protect with aces is the jcr:content subnode
>> because of its fixed name.
>>
>
> You are right I guess there is a difference in what you're trying to do that
> proposed solution. The structure administrators would be able to rename
> Entity1b (maybe delete too, not sure the behavior with a patter based
> setting like that). For some people that works because they still consider
> that structure, where they still can't get to the real content (besides
> deleting?).
>
> I think you still may be able to work with that idea though, if the only
> deterrent is ugly path names. Could you use sling to hide the ugliness and
> keep the functionality you need?
Not sure about this one. I'll check that later.
> Or maybe just something that looks cleaner
> such as everything that begins or ends with an underscore?
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/Conditional-access-control-tp3891814p3894980.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
Re: Conditional access control
Posted by Mark Herman <MH...@NBME.org>.
Markus Joschko wrote:
>
> Guess I still miss a piece.
> How do I prevent somebody with write/delete/modify rights to Suisse to
> also modify the Entity1b node?
> The only node I can protect with aces is the jcr:content subnode
> because of its fixed name.
>
You are right I guess there is a difference in what you're trying to do that
proposed solution. The structure administrators would be able to rename
Entity1b (maybe delete too, not sure the behavior with a patter based
setting like that). For some people that works because they still consider
that structure, where they still can't get to the real content (besides
deleting?).
I think you still may be able to work with that idea though, if the only
deterrent is ugly path names. Could you use sling to hide the ugliness and
keep the functionality you need? Or maybe just something that looks cleaner
such as everything that begins or ends with an underscore?
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Conditional-access-control-tp3891814p3894980.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Conditional access control
Posted by Markus Joschko <ma...@gmail.com>.
Guess I still miss a piece.
How do I prevent somebody with write/delete/modify rights to Suisse to
also modify the Entity1b node?
The only node I can protect with aces is the jcr:content subnode
because of its fixed name.
On Tue, Oct 11, 2011 at 5:34 PM, Mark Herman <MH...@nbme.org> wrote:
>
> Mark Herman wrote:
>>
>> You'll see that the nt:file has a jcr:content property of it which
>> actually holds the jcr:data property.
>>
>
> Correction: nt:file has a jcr:content CHILD NODE (usually nt:resource) which
> will have the jcr:data property.
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/Conditional-access-control-tp3891814p3894840.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
Re: Conditional access control
Posted by Mark Herman <MH...@NBME.org>.
Mark Herman wrote:
>
> You'll see that the nt:file has a jcr:content property of it which
> actually holds the jcr:data property.
>
Correction: nt:file has a jcr:content CHILD NODE (usually nt:resource) which
will have the jcr:data property.
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Conditional-access-control-tp3891814p3894840.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Conditional access control
Posted by Mark Herman <MH...@NBME.org>.
Markus Joschko wrote:
>
> OK, if I got you right then it should look like
>
> Europe
> | |-jcr:content
> | |-...
> |-Suisse
> | |-jcr:content
> |-Germany
> | |-jcr:content
> |-Bavaria
> | |-jcr:content
> | ...
>
> And then the restriction might look like */jcr:content/* if I want to
> add/remove rights from the entities.
>
> That is certainly workable however I have an issue with that:
> We are using sling where the path is reflected in the URL and a path
> like /europe/germany/jcr:content/entity1 looks quite bad.
> And as we have three different node types the path would look even
> worse: /europe/germany/jcr:content/entity1/jcr:content/subentity
>
The way I understood it Angela was referring to using the actual node type
nt:file. You'll see that the nt:file has a jcr:content property of it which
actually holds the jcr:data property. So every time you're accessing content
you are really going through a jcr:content at the very end. More like this:
Europe
|-Entity1a
| |-jcr:content
|-Suisse
| |-Entity1b
| |-jcr:content
| |-Entity2b
| |-jcr:content
|-Germany
| |-Entity1c
| |-jcr:content
|-Bavaria
| ...
Since you're using Sling, it should be fairly easy either create a
resourceType or modify the default handlers to assume that consistent
subnode and it doesn't have to appear in the URL. That is pretty much what
sling already does with nt:file, going to /path/to/filename will actually
get you /path/to/filename/jcr:content/jcr:data automatically. You can
choose to use nt:file or do the same thing on your own node type pretty
easily.
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Conditional-access-control-tp3891814p3894832.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Conditional access control
Posted by Markus Joschko <ma...@gmail.com>.
Hi Angela,
> custom privilege can either be new aggregates of built-in privileges
> or something really custom. the former is taken into account when
> evaluation permissions for operations being executed on the repository
> (such as read or write). the latter don't have any meaning inside
> jackrabbit and therefore need to be checked and enforced by those
> applications that make use of them.
OK, I thought I am not able to register them at all if they are not aggregates.
That's already valueable.
>
>> - an alternative might be to create new accesscontrol entries that do
>> not only have path restrictions but also nodetype restrictions.
>> However that seems to be quite invasive and a lot of work.
>
> yes... that's true. in addition you would need to evaluate the
> effective node type of the nodes and that's currently quite expensive.
I fear that there is no way around that. But that only applies to
write/delete/modify
scenarios which are relatively rare in my scenario so the performance
hit is most likely acceptable.
>
>> Any other ideas how to tackle that problem?
>
> what do you mean by 'maintain folders' and 'maintain files'?
> what kind of operations does that include?
>
> a common use case i am aware of is that some principals are allowed to
> modify the hierarchy of a tree and others are allowed to edit
> the files in there by manipulating everything below jcr:content.
> that case can usually be covered by path-based restrictions.
That is basically also my use case. The tree is a regional structure like
Europe
| - Suisse
| |...
| - Germany
| - Bavaraia
|-....
Within this structure there are different entities stored. Only a
certain group of users can maintain
the structure of a branch (e.g the germany branch). Maintaining means
create/modify/delete the structure elements.
Another group of users maintains the entities within that structure
but only has read access (add childNodes) to the structure itself
>
> in other words: the different child-item definitions of the file
> vs the folder node type allows to get along with path-based restrictions.
> defining node types with named child item
> definitions will make sure that your content follows your
> naming conventions.
OK, if I got you right then it should look like
Europe
| |-jcr:content
| |-...
|-Suisse
| |-jcr:content
|-Germany
| |-jcr:content
|-Bavaria
| |-jcr:content
| ...
And then the restriction might look like */jcr:content/* if I want to
add/remove rights from the entities.
That is certainly workable however I have an issue with that:
We are using sling where the path is reflected in the URL and a path
like /europe/germany/jcr:content/entity1 looks quite bad.
And as we have three different node types the path would look even
worse: /europe/germany/jcr:content/entity1/jcr:content/subentity
>
> other possibility was to organize your content such that applying
> access control restrictions feels natural...
Unfortunately the hierarchy of regions is fixed so I can not easily
reorganize the content.
Thanks for your input,
Markus
Re: Conditional access control
Posted by Angela Schreiber <an...@adobe.com>.
hi markus
On 10/10/11 11:02 PM, Markus Joschko wrote:
> Hi,
> In my repository I have a structure that has many deep branches.
> Within these branches there are three different types of nodes.
> Each type is maintained by another group of users. These groups can be
> configured per branch
> (it's a bit like in a file system where one group can only maintain
> the folders and the other group only the files in a branch).
>
> Now the question is how to best handle the access control here.
> I can:
> - either add an ace to each and every node in the repository and pay
> the price that I have to maintain a lot of them in case ownership of a
> branch changes or subbranches are moved into different branches.
> - find a way to hook into the accesscontrol mechanism of jackrabbit to
> make this easier. So far I have failed to find a good way to do so.
> I initially thought about introducing custom privileges that can be
> used as markers and then extend the ACLProvider to take these
> privileges also into account when calculating permissions.
> However from looking at the code it seems to me, that custom
> privileges can only be defined as aggregates of existing privileges
> and then also the aggregate can not exist twice. I guess it is not a
> good idea to create artificial aggregates just to define new privileges.
custom privilege can either be new aggregates of built-in privileges
or something really custom. the former is taken into account when
evaluation permissions for operations being executed on the repository
(such as read or write). the latter don't have any meaning inside
jackrabbit and therefore need to be checked and enforced by those
applications that make use of them.
> - an alternative might be to create new accesscontrol entries that do
> not only have path restrictions but also nodetype restrictions.
> However that seems to be quite invasive and a lot of work.
yes... that's true. in addition you would need to evaluate the
effective node type of the nodes and that's currently quite expensive.
> Any other ideas how to tackle that problem?
what do you mean by 'maintain folders' and 'maintain files'?
what kind of operations does that include?
a common use case i am aware of is that some principals are allowed to
modify the hierarchy of a tree and others are allowed to edit
the files in there by manipulating everything below jcr:content.
that case can usually be covered by path-based restrictions.
in other words: the different child-item definitions of the file
vs the folder node type allows to get along with path-based
restrictions. defining node types with named child item
definitions will make sure that your content follows your
naming conventions.
other possibility was to organize your content such that applying
access control restrictions feels natural...
hope that helps
angela
Re: Conditional access control
Posted by Markus Joschko <ma...@gmail.com>.
Hi Alex,
principal-based ACL do not ease the setup. The real problem is, that
the nodes with the different types are mixed in the hierarchies.
So even with principal based ACLs I have to define the ACLs for each
path separately which is not much easier to maintain the resource
based ACLs.
Regards,
Markus
On Tue, Oct 11, 2011 at 12:15 AM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> On 10.10.11 23:02, "Markus Joschko" <ma...@gmail.com> wrote:
>
>>Hi,
>>In my repository I have a structure that has many deep branches.
>>Within these branches there are three different types of nodes.
>>Each type is maintained by another group of users. These groups can be
>>configured per branch
>>(it's a bit like in a file system where one group can only maintain
>>the folders and the other group only the files in a branch).
>>
>>Now the question is how to best handle the access control here.
>>I can:
>>- either add an ace to each and every node in the repository and pay
>>the price that I have to maintain a lot of them in case ownership of a
>>branch changes or subbranches are moved into different branches.
>>- find a way to hook into the accesscontrol mechanism of jackrabbit to
>>make this easier. So far I have failed to find a good way to do so.
>> I initially thought about introducing custom privileges that can be
>>used as markers and then extend the ACLProvider to take these
>>privileges also into account when calculating permissions.
>> However from looking at the code it seems to me, that custom
>>privileges can only be defined as aggregates of existing privileges
>>and then also the aggregate can not exist twice. I guess it is not a
>>good
>> idea to create artificial aggregates just to define new privileges.
>>- an alternative might be to create new accesscontrol entries that do
>>not only have path restrictions but also nodetype restrictions.
>>However that seems to be quite invasive and a lot of work.
>>
>>Any other ideas how to tackle that problem?
>
> Principal-based ACLs maybe?
>
> Alex
>
> --
> Alexander Klimetschek
> Developer // Adobe (Day) // Berlin - Basel
>
>
>
>
>
Re: Conditional access control
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 10.10.11 23:02, "Markus Joschko" <ma...@gmail.com> wrote:
>Hi,
>In my repository I have a structure that has many deep branches.
>Within these branches there are three different types of nodes.
>Each type is maintained by another group of users. These groups can be
>configured per branch
>(it's a bit like in a file system where one group can only maintain
>the folders and the other group only the files in a branch).
>
>Now the question is how to best handle the access control here.
>I can:
>- either add an ace to each and every node in the repository and pay
>the price that I have to maintain a lot of them in case ownership of a
>branch changes or subbranches are moved into different branches.
>- find a way to hook into the accesscontrol mechanism of jackrabbit to
>make this easier. So far I have failed to find a good way to do so.
> I initially thought about introducing custom privileges that can be
>used as markers and then extend the ACLProvider to take these
>privileges also into account when calculating permissions.
> However from looking at the code it seems to me, that custom
>privileges can only be defined as aggregates of existing privileges
>and then also the aggregate can not exist twice. I guess it is not a
>good
> idea to create artificial aggregates just to define new privileges.
>- an alternative might be to create new accesscontrol entries that do
>not only have path restrictions but also nodetype restrictions.
>However that seems to be quite invasive and a lot of work.
>
>Any other ideas how to tackle that problem?
Principal-based ACLs maybe?
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel