Am Donnerstag 02 Oktober 2008 06:26:44 schrieb Howard Chu:
I was dusting off some of the last rfc2307bis revisions Luke sent me, and then remembered how much of a mess we still have with groups. Here are some ideas I'm toying with, would like some feedback before drafting for IETF-LDAPext.
Nice, to see that something is going on in that area. :)
We already know that groupOfUniqueNames is misleading and should be avoided. The big problem with groupOfNames is that member is required. So my first thought was a new groupOfMembers objectclass where member is optional (MAY instead of MUST).
Along the way I was thinking that perhaps a different concept was needed here, like setOfNames instead. The main thinking being: sets implicitly have unique membership sets may be empty sets may be comprised of other sets
This presents a single solution to the whole static/dynamic/nested groups mess: setOfReferences.
The (multivalued of course) "reference" attribute is a URI. if it's in the form of a plain DN, then it is the DN of a single member. if it's in the form of an absolute qualified URI (i.e., it begins with a "ldap:///" spec) then it dereferences the URI to derive the members.
For a nested group, you would use ldap:///cn=foo,o=bar?reference?base
which would join (union) the values of the referenced entry's reference attribute to this set.
One problem with this could be, that would be impossible to find out which nested groups a certain group is a member of. With the direct DN references ("member"-Attribute) that was still possible. If you would allow nested groups in the rfc2307bis revision that might become a problem. Think of e.g. the getgrouplist(), initgroups()s calls.
For a dynamic group you would use something like ldap:///ou=foo,o=bar?entryDN?subtree?(HasWhatIWant=TRUE)
Obviously a "nested group" is now just a special case of a dynamic group. The main point here is that you can immediately tell by inspection whether a further dereference is needed or not.
Furthermore we can incorporate specific Identity values into *each* dereference, using URI extensions: ldap:///ou=foo,o=bar?entryDN?subtree?(HasWhatIWant=TRUE)?X-refAuthID=cn=jo e%2c,o=bar
We could probably do the same for AuthZ although it would get awkward to specify a list of authorized proxiers. That would itself have to be another reference to accomodate multiple values.
This gives us a clean, consistent syntax and semantic for grouping behavior. It doesn't make our lives any easier as far as indexing and optimizing the dynamic characteristics, but it's a start. Thoughts?