From dev-return-5984-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed May 18 05:09:31 2005 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 94640 invoked from network); 18 May 2005 05:09:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 May 2005 05:09:31 -0000 Received: (qmail 6169 invoked by uid 500); 18 May 2005 02:41:43 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 6128 invoked by uid 500); 18 May 2005 02:41:42 -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 6100 invoked by uid 99); 18 May 2005 02:41:42 -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.70 as permitted sender) Received: from imf22aec.mail.bellsouth.net (HELO imf22aec.mail.bellsouth.net) (205.152.59.70) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 17 May 2005 19:41:40 -0700 Received: from ibm65aec.bellsouth.net ([65.80.200.112]) by imf22aec.mail.bellsouth.net (InterMail vM.5.01.06.11 201-253-122-130-111-20040605) with ESMTP id <20050518024125.BQFM2059.imf22aec.mail.bellsouth.net@ibm65aec.bellsouth.net> for ; Tue, 17 May 2005 22:41:25 -0400 Received: from [172.16.1.7] (really [65.80.200.112]) by ibm65aec.bellsouth.net (InterMail vG.1.02.00.01 201-2136-104-101-20040929) with ESMTP id <20050518024125.YBXU26760.ibm65aec.bellsouth.net@[172.16.1.7]> for ; Tue, 17 May 2005 22:41:25 -0400 Message-ID: <428AAB54.8030007@bellsouth.net> Date: Tue, 17 May 2005 22:41:24 -0400 From: Alex Karasulu User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@directory.apache.org Subject: [apacheds] ACL implementation options (was ACLs questions) 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 Hello, I thought I'd start a new thread since some of these ideas transcend what we were talking about. Also it helps to hit that reset button sometimes :). Just to give you all some background I had a long conversation with Noel about approaching ACLs in a fashion where any approach could eventually be taken for representing and storing them. By tossing around these ideas we came up with some implementation possibilities. I'd like to summarize them here on this thread and open our conclusions to some discussion. First off, we both agreed that we need some optimized in memory data structure to represent access control information. The ACL data representation within this structure is the operational representation for efficient AC evaluations. What this structure will be at the present moment is irrelavent. We both agreed that something optimized for evaluation is key for performance reasons. Now with this data structure the implementation of the authorization subsystem is trivial. An interceptor is used to reject, alter or allow various operations on entries based on the evaluation of these access control instructions within the optimized structure. 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. 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. 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. -Alex