Re: Using forward references and filters in ACLs in OpenLDAP

[Christoph Neumann <enigma@apu.edu>]

This seems like a useful feature.  I think you can impliment a similar 
thing via the "set" directive.  For example, you had

> access to filter=(invisible=true)
> 	by filter=(role=staff) read
> 	by filter=(role=student) none

Currently, with the "set" directive, you could do this:

access to filter=(invisible=true)
  by set="user/role & [staff]" read
  by set="user/role & [student]" none

You can find more information on the "set" directive at
http://www.openldap.org/faq/data/cache/452.html

Despite the "set" directive's weak documentation, it is a very powerful
construct.  Since you can dereference attributes with the
"distinguishedName" syntax, you can easily create relationships between
different entries (such as "this/manager & user").  Here at APU, we have
used it to support groups within groups using something like
"cn=MetaGroup,dc=apu,dc=edu/member/member & user".

I think your proposal for a filter based "who" clause is more intuative
than the set directive and might serve as a good alternative.

- Christoph


On Tue, 16 Jul 2002, Mads Freek wrote:

> Almost a year agon I asked on this list if it were possible to 
> use filter clauses in the by part of the ACLs in OpenLDAP (a 
> filter checked against the binded user). Pierangelo Masarati was 
> kind enough to answer that is wasn't possible and that it 
> probably was to costly an operation anyway.
> 
> Yesterday I was looking at the code implementing the group 
> clause in the by part of the ACLs and it hit me that by 
> switching two parameters (the dn of the group and the dn of the 
> user) I would be able to use forward referencing ie. basing 
> group membership on the value of an attribute of an entry 
> instead of listing the dn of an entry as a value of an attribute 
> of the group.
> 
> Expressed as ldap urls the current code checks if this evaluates 
> to true (ie the filterpart would select the dn if used in a 
> search) :
> 
> ldap:///<dn of group>??one?(&(objectclass=<group object 
> class>)(<member attribute>=<dn of user>))
> 
> by getting the group entry and checking for objectclass and 
> member attribute.
> 
> By switching the group and the user dn parameters (and dropping 
> the objectclass check) this becomes:
> 
> ldap:///<dn of user>??one?(<member attribute>=<dn of group>)
> 
> A full dn for the group isn't needed so this becomes:
> 
> ldap:///<dn of user>??one?(<some attribute>=<some value>)
> 
> which doesn't seem more costly to evaluate than the original url above.
> 
> While working with this it hit me that if it were so easily 
> expressed as a filter why not implement it as general filter 
> checking instead of a specialized group checking.
> 
> So I have made a simplified bdb_group (based on 2.1.3) which 
> basically take a dn and a filter. Using this I have made some 
> changes in the acl part of the code to allow access clauses like:
> 
> access to filter=(invisible=true)
> 	by filter=(role=staff) read
> 	by filter=(role=student) none
> 
> 
> and some changes in the limit code to allow limits clauses like:
> 
> limits  filter=(role=staff) size=500
> limits  filter=(role=student) size=25
> 
> (both examples examplifies existing problems in our current 
> implementation of LDAP at Roskilde University.  The students are 
> allowed to mark their entry invisible for the world and for 
> other students, but not for staff members. I don't want to 
> introduce static groups or branches in the tree to solve this. 
> Likewise staff members are allowed to se more entries than the 
> world or the students and enforcing this has to my knowledge 
> only been possible using branches.)
> 
> I am sending this preliminary report to the list to se if there 
> is some interest in adding this feature to OpenLDAP.
> 
> If so I would suggest  that a back_filter function is added to 
> the backend api and that the filter and the group ACLs might be 
> implemented (at least in back-bdb) using this. The existing per 
> connection GroupAssertion cache could then be replaced by a 
> FilterAssertion cache - caching both group and filter use.
> 
> 
> Regards Mads Freek
> 
> ------------------------------------------------------
> Mads Freek Petersen
> Computer Science Department
> Roskilde University
> Building 42-1, P.O. Box 260, DK-4000 Roskilde, Denmark
> 
> Phone:  +45 4674 3882
> Fax:    +45 4674 3072
> E-mail: freek@ruc.dk
> 
> 
>