directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Blanchard <>
Subject Re: [apacheds] ACL implementation options (was ACLs questions)
Date Wed, 18 May 2005 07:17:36 GMT

Alex Karasulu a écrit :

> 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.
Agree with this.

> 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...

> 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 ?
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 
In fact, we do not need to compute ACLs for some entries which are never 
used by a user..
There is some possible drawbacks for memory size but it saves some 
computation time to compare ACL with a user.
Maybe also we could enable everyone to implement different strategies on 
authorization, principals and ACLs in memory management.

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.

> 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.

> -Alex

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 ? ;-)

Best regards,

View raw message