Re: groups, rfc

[Ralf Haferkamp <rhafer@suse.de>]

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?