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?
