From users-return-18224-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Oct 10 22:17:06 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 664E97A51 for ; Mon, 10 Oct 2011 22:17:06 +0000 (UTC) Received: (qmail 13080 invoked by uid 500); 10 Oct 2011 22:17:05 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 13043 invoked by uid 500); 10 Oct 2011 22:17:05 -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 13035 invoked by uid 99); 10 Oct 2011 22:17:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 22:17:05 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aklimets@adobe.com designates 64.18.1.189 as permitted sender) Received: from [64.18.1.189] (HELO exprod6og105.obsmtp.com) (64.18.1.189) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 22:16:55 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP; Mon, 10 Oct 2011 15:16:35 PDT Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9AMGWrg007951 for ; Mon, 10 Oct 2011 15:16:32 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9AMCj5k028361 for ; Mon, 10 Oct 2011 15:16:30 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 10 Oct 2011 15:15:51 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Mon, 10 Oct 2011 23:15:50 +0100 From: Alexander Klimetschek To: "users@jackrabbit.apache.org" Date: Mon, 10 Oct 2011 23:15:46 +0100 Subject: Re: Conditional access control Thread-Topic: Conditional access control Thread-Index: AcyHmioxr3Ui3mODR0uP+n7j9sHazg== Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org On 10.10.11 23:02, "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. >- 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 --=20 Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel