> X.500 subentries are recommended to store various > information for an > autonomous administrative area. The area can be for > schema, ACLs, or > collective attributes. The area of coverage for the > contained > information in the subentry is defined by the > subtree specification > which includes parameters for chop before, chop > after, and subtree > refinements. This is all X.500 stuff that the LDAP > community is > reintroducing today. One can almost say there is a > subtle convergence > going on. >
Well, there's allways a difference between "theoretical" truths and "practical" truths. While it might seem that it makes the most sence to store ACL entries in a subtree, the implementation and performace is not practical. For instance, what if you have an ACL that defines a restriction on reads of the "sn" attribute for anything subtree of "dc=domain,dc=com". When processing the entry "uid=test,ou=Users,dc=test,dc=domain,dc=com". You could allways travers the DN backworkds to get all the ACLs and cache those acls so you don't need to find them again in the request, but that seems like a lot of overhead (on top of the ACL processing overhead). A second practical issue is managment. Instead of managing all your ACLs in one place, now you have to manage it on each node. Seaches could show you all of the acls in a single report, but now it makes management a bit harder. Finally, what about custom partitions and remote services? (LDAP Proxy, DB Partition). Now you need each partition to be responsible for it's own ACL processing. So while in a stand alone directory environment with simple ACLs using a sub entry may be the easiest way to go, but when you have a large envuronment with other types of partitions this could become combersome quickly. > > If you want to commit to something we can explore > implementing > subentries together first. Next we need to include > support for schema > structures for subtree specifications and algorithms > for subtree entry > set inclusion evaluation. Finally we can begin > talking about > implementing the actual ACL mechanism - IMO the ACL > mechanism can be > developed in parallel and stored somewhere else > until we complete these > components in parallel. This way Tony can begin > working with us as well. As much as I would like to contribute, I simply don't have time to share anything but my experience. Marc
