directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Blanchard <blt...@wanadoo.fr>
Subject ACLs questions
Date Sat, 14 May 2005 09:56:25 GMT
Hello,
I have two questions for the futur of ACLs with apacheds.

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 :
"    private boolean isSearchable( LdapContext ctx, SearchResult result )
            throws NamingException
    {
        Name dn;

        synchronized ( dnParser )
        {
            dn = dnParser.parse( result.getName() );
        }

        Name principalDn = ( ( ServerContext ) ctx ).getPrincipal().getDn();
        if ( !principalDn.equals( ADMIN_DN ) )
        {
            //New code
            if (principalDn.equals(dn))
            {
                return true;
            }
        //End of new code
            
            if ( dn.size() > 2 ) [...]"

2 - What about having an "openLDAP like" simplified ACL mechanism ?

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 ?
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 Blanchard




Mime
View raw message