directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject [apacheds] ACL implementation options (was ACLs questions)
Date Wed, 18 May 2005 02:41:24 GMT
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







Mime
View raw message