From dev-return-6011-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed May 18 23:07:09 2005 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 91983 invoked from network); 18 May 2005 23:07:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 May 2005 23:07:08 -0000 Received: (qmail 72816 invoked by uid 500); 18 May 2005 21:35:30 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 72618 invoked by uid 500); 18 May 2005 21:35:28 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 72469 invoked by uid 99); 18 May 2005 21:35:27 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=FROM_ENDS_IN_NUMS,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of aok123@bellsouth.net designates 205.152.59.66 as permitted sender) Received: from imf18aec.mail.bellsouth.net (HELO imf18aec.mail.bellsouth.net) (205.152.59.66) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 18 May 2005 14:35:25 -0700 Received: from ibm61aec.bellsouth.net ([65.80.200.112]) by imf18aec.mail.bellsouth.net (InterMail vM.5.01.06.11 201-253-122-130-111-20040605) with ESMTP id <20050518213517.YKSP2152.imf18aec.mail.bellsouth.net@ibm61aec.bellsouth.net> for ; Wed, 18 May 2005 17:35:17 -0400 Received: from [172.16.1.7] (really [65.80.200.112]) by ibm61aec.bellsouth.net (InterMail vG.1.02.00.01 201-2136-104-101-20040929) with ESMTP id <20050518213516.NUDZ1498.ibm61aec.bellsouth.net@[172.16.1.7]> for ; Wed, 18 May 2005 17:35:16 -0400 Message-ID: <428BB514.6020806@bellsouth.net> Date: Wed, 18 May 2005 17:35:16 -0400 From: Alex Karasulu User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [apacheds] ACL implementation options (was ACLs questions) References: <428AAB54.8030007@bellsouth.net> <428AEC10.2080707@wanadoo.fr> In-Reply-To: <428AEC10.2080707@wanadoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Tony Blanchard wrote: >> Noel stressed the point that an API should be exposed to add and >> remove ACLs from this data structure. By exposing such an API ACLs >> can be added to the structure at runtime or at initialization time >> using ACL information stored anywhere in any format. Meaning the >> existance of this API makes our authorization evaluation mechanism >> independent of the way ACLs are stored or where and how they are >> represented syntactically. This is very important because it makes >> our conversations on the other thread moot. We can do ACLs any way >> we like ... via OpenLDAP compatible flat files or using subentries. >> Even the syntax of ACL/ACI specification need not be the same. What >> ever the format some code would parse it and add the ACI/ACL set to >> the authz subsystem using this API which adds the respective ACL >> elements to the data structure used for evaluation. > > > I think ACLs with OpenLDAP are too much complicated and the > declaration order notion of ACLs in OpenLDAP seems to me dangerous in > some ways... > And the OpenLDAP file format is not realy java nor modern... > Hokay but the option of doing this is available and that may be comforting. Personally I don't have enough knowledge at this point to home in on a format myself :). >> The question now is where this specialized structure should be and >> what should expose this API. It's obvious the authorization >> subsystem should manage the data structure since it must make the AC >> decisions to effect directory operation within the interceptor >> chain. Also for this reason the authz system should expose the API. > > > I have a question about this. It may be naiv but what about > computing ACLs from ACLs storage (subentries or other) at > authentication time. Once authenticated, ACLs are computed from the > point of view of the authenticated user and then attached to the > principal ? Not a bad idea at all. Basically we're computing ACLs on session creation. Might be a cheaper route then to keep all ACLs in memory from the start. > This not needs to be a complete computation and can enlarge each time > a new access is done to an entry by the user ? This way, we build a > kind of cache about ACLs permissions and preffered paths in the tree > for that user. So ACL has already made choice for what the user can do > or not. If the user can not go under an entry, do not compute ACLs > which are not relevant. Yes thinking some more about this it makes what ever data structure we faster since it prunes down the search space for evaluations. It will make the server more performant when it comes to ACL evaluations. > Note: There are some ACLs which are not relevant for user principal. I > think about ACLs dependant on URLs... So I think there are different > ACLs kinds and dynamic strategies should differ. > Makes sense +1. >> >> So how does this help Tony, Marc, and myself as well as others >> interested in this thread? Well consider the two options put forth >> already. One was to use OpenLDAP ACL syntax and file format. In >> this case a parser would parse the file at startup and add the >> ACI/ACLs into the authz subsystem using the exposed API. This would >> not be conducive to replication but it would be the same as what >> OpenLDAP has. Plus it is not dynamic. >> >> >> In the case of using subentries to store ACLs, at startup, all ACLs >> in subentries would be added to the data structure using the API's of >> the authz subsystem. The interceptor for the authz subsystem would >> pay special attention to any subentry changes to add, remove or >> modify ACI/ACLs via the authz API. This would be dynamic. This way >> when subentries replicate with a subtree they trigger ACL changes to >> the authz subsystem of replicas. Meaning ACLs are replicated with >> the data they control and evaluation is still optimized. > > > Depend on what I said previously regarding the principal holding ACLs > made decisions. But I agree this second option is better. And I agree > there should be a observer for the changes on tree. We think alike :). But no you have a very interesting point about building the specialized ACL structure for the user when the session is established. It might cost less I think actually. > As we advance on this thema, should put some validated ideas expressed > here on the wiki page for ACLs. Maybe we could make a first version at > the end of the week to let a maximum of people to participate to this > thread ? WDYT about it ? ;-) Good idea let's just keep compiling the ideas. I want to carve up serious time for this and start work on some implementation soon. Regards, Alex