jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Joschko <markus.josc...@gmail.com>
Subject Re: Conditional access control
Date Tue, 11 Oct 2011 08:06:26 GMT
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

Mime
View raw message