[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
groups, rfc
- To: OpenLDAP Devel <openldap-devel@openldap.org>
- Subject: groups, rfc
- From: Howard Chu <hyc@symas.com>
- Date: Wed, 01 Oct 2008 21:26:44 -0700
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b1pre) Gecko/20080917130338 SeaMonkey/2.0a1pre
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?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/