jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Conditional access control
Date Tue, 11 Oct 2011 06:52:25 GMT
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

View raw message