directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [apacheds] ACL implementation options (was ACLs questions)
Date Wed, 18 May 2005 21:35:16 GMT
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. 


View raw message