directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: ACLs questions
Date Mon, 16 May 2005 06:00:53 GMT
Tony Blanchard wrote:

> Hello,
> I have two questions for the futur of ACLs with apacheds.

I have some too :).

> 1 - I have noticed there was not user read access on the 
> uid=self,ou=users,ou=system and I think it should be.
> I have modified the "isSearchable" operation on AuthorizationService 
> to enable read operation on the "self" entry and not for the others.
> What do you think about this and is it possible to add this code to 
> the class :

I thought we had full read access on self entries.  Could you show the 
lack of this with a test case addition patch, then post this code to a 
JIRA issue? This way we don't forget about it and can confirm the fix 
easily.  Nice to isolate the problem with a test case as well.

<snip/>

>
> 2 - What about having an "openLDAP like" simplified ACL mechanism ?
>
I don't know I have not put enough thought to this because there are so 
many things standing in my way right now like implementing subentires so 
we can store ACLs ;).  However going with their scheme might be a good 
idea.  Can you take the time to research the strengths and weaknesses 
with this approach? 


Are there other options?  What are the performance implications?


We could certainly build authz into the directory very rapidly.  I would 
however like to research how different directories do authz first.


> Here are the properties which should be used to register the ACLs to 
> the server :
>
> server.db.partitions.{id}.access.whatid=whatdn //Mandatory: Maybe a 
> regexp or an exact dn
> server.db.partitions.{id}.access.whatid.filter=An LDAPFilter  //Optional:
> server.db.partitions.{id}.access.whatid.scope={exact|one|sub|children} 
> //Mandatory:
> server.db.partitions.{id}.access.whatid.whoid=whodn //Maybe a regexp 
> or a whodn space separated list //Mandatory:
> server.db.partitions.{id}.access.whatid.attributes=attr space 
> separated list //Optional: not valid for some scope types...
> server.db.partitions.{id}.access.whatid.level={none|auth|read|write} 
> //Mandatory:
> server.db.partitions.{id}.access.whatid.special_level=self //Optional: 
> allows  special  operations  like having a certain
>                                                           access level 
> or privilege only in case the operation
>                                                           involves 
> the  name of  the    user  that's  requesting
>                                                           the access.
>
> Maybe The Authentication service should load ACLs at runtime (be 
> carefull of regexps for "whodn") and attach them to the
> principal wich is accessible from the AuthorizationService.
> Then, the authorization service should look for them each time an call 
> is made...
>
> What do you think about it ?

Nothing yet.  I'll try to free up some time to give this more traction.  
These links below help.  Please feel free to put them up on our Wiki, 
create your own Authz page and add these links and other research to them. 

> Please take a look at the openLDAP documentation to compare this to an 
> existing ACLs implementation :
> - http://www.openldap.org/doc/admin22/slapdconfig.html#Access%20Control
> - 
> http://www.openldap.org/software/man.cgi?query=slapd.access&apropos=0&sektion=5&manpath=OpenLDAP+2.2-Release&format=html

>

Thanks Tony,

Alex

Mime
View raw message