From users-return-18228-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Oct 11 08:06:58 2011 Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F39F49CBA for ; Tue, 11 Oct 2011 08:06:57 +0000 (UTC) Received: (qmail 18593 invoked by uid 500); 11 Oct 2011 08:06:57 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 18473 invoked by uid 500); 11 Oct 2011 08:06:56 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 18047 invoked by uid 99); 11 Oct 2011 08:06:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2011 08:06:54 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of markus.joschko@gmail.com designates 209.85.161.170 as permitted sender) Received: from [209.85.161.170] (HELO mail-gx0-f170.google.com) (209.85.161.170) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2011 08:06:47 +0000 Received: by ggnk1 with SMTP id k1so10263855ggn.1 for ; Tue, 11 Oct 2011 01:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9yjPd0bcy8lue6/aPgv2AL/ccWO4Kd12MAuwgSK+mQ4=; b=Zh5M7NSVrvMIo201QWys8fivm9br2dGdsYwmyE4poUhcTLHsYZhJztAbd83Sy23Rqd Wy89myIPAQ43piZRgZlGYOsr3N2LHofHrH4L3HOzhz2KZjQWrenAdWKezU0SJpRT0ndH Xl0DTxAi+eTKbCWkAq5NcAxw+qtzfsCwzjvHI= MIME-Version: 1.0 Received: by 10.236.129.228 with SMTP id h64mr28808252yhi.101.1318320386157; Tue, 11 Oct 2011 01:06:26 -0700 (PDT) Received: by 10.236.103.19 with HTTP; Tue, 11 Oct 2011 01:06:26 -0700 (PDT) In-Reply-To: <4E93E7A9.9050904@adobe.com> References: <4E93E7A9.9050904@adobe.com> Date: Tue, 11 Oct 2011 10:06:26 +0200 Message-ID: Subject: Re: Conditional access control From: Markus Joschko To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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