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.
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.
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=joe%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?
On Thu, Oct 2, 2008 at 2:26 PM, Howard Chu hyc@symas.com wrote:
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.
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
I think this is a good idea, but for the concept to be accurate, i'm assuming if you had two members, such as :
ldap:///ou=foo,o=bar?entryDN?subtree?(deptCode=XYZ) ldap:///ou=foo,o=bar?entryDN?subtree?(deptCode=ABC)
The idea above is just to play devils advocate, i.e. what if somebody is in both groups, the proposed solution then would (to maintain the set paradigm) need to remove the duplicate dn's. If it was not described as a "set" then you could just leave the duplicates for a simpler implementation.
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?
It would be nice if the underlying group linkage were abstracted away from using the dn exclusively.
One thing that is currently an occasional bain, is group membership which is only specified by dn as the underlying linking attribute, especially in a highly dynamic tree structure that is being revised or changed (either small or large) every few months. Any group whose members are specified by dn are broken whenever any part of that DN 's components are restructured / moved or renamed.
Any highly structured organisation which is large enough for this to be a problem, is also very likely going to have it's own unique identifiers (employee number etc.,) which would already be suitable for linking users to groups, rather than being forced to link users/groups by dn which is subject to change.
It would therefore be nice to be able to abstract the underlying membership linkage for a group without being forced to use dn's as the user/group linking paradygm. This does not necessarily imply changing the dn as seen by the client, as when group members are being mapped from the dynamic list, it could just present the dn, no matter what was used internally
This does mean that the presented dn's will automatically reflect structure changes, if the underlying unique name matching attribute has not actually changed. This implies that groups can use some more immediately useful or efficient underlying linkage, even if dns are still presented to and accepted from, the ldap client.
Cheers Brett
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?
Ralf Haferkamp wrote:
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.
Note that nss_ldap today already uses nested groups, it simply recursively looks up everything. (And that can be quite expensive right now.) At the very least we should have an immediate way to differentiate simple DNs from nested group references to eliminate unnecessary recursions here.
Am Donnerstag 02 Oktober 2008 10:20:10 schrieb Howard Chu:
Ralf Haferkamp wrote:
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.
Note that nss_ldap today already uses nested groups, it simply recursively looks up everything. (And that can be quite expensive right now.)
Yes, I know. But was wondering how exactly one could make reverse lookups (what (nested) groups is userX member of) working with the above schema. Those lookups would be needed by the above mentioned NSS functions.
At the very least we should have an immediate way to differentiate simple DNs from nested group references to eliminate unnecessary recursions here.
Yes, that would of course be helpful. The most obvious approach would be to introduce differnt types of "reference" Attributes. E.g. "dnReference" for "normal" groupsmembers, "nestedDnReference" of nested members and "uriReference" of dynamic members. As I guess you have already thought about such an approach, what are the disadvantages of those?
-
Brett ＠Google -
Howard Chu -
Ralf Haferkamp