[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Summary of group discussion

Andrew,
I didn't have a chance to follow the complete discussion thread.  So,
I'm taking the liberty to comment on the items that you mentioned in
this summary.

Andrew Findlay wrote, On 09/25/2007 01:13 AM:
> Most people who joined the discussion on ldapext@ietf.org were broadly
> in support of allowing empty groups, though some thought that any
> changes away from the status quo were doomed to fail.

I'm in agreement as well.  We already support empty group though its
against the standard.

> Luke Howard suggested that the behaviour of nested groups should be
> defined. I was initially against an explicit definition, but was soon
> persuaded that there could be significant performance and security
> problems with ad-hoc nesting. At this point the discussion moved
> almost entirely to the consideration of nesting issues.

Good suggestion.  This is very much needed for interoperability as more
and more vendors supporting nested groups.

> Pete Rowley wanted an interface to be used by read-only clients to find
> out what groups a particular entry is a member of without caring about
> how the groups are defined. He suggested a memberOf attribute (presumably
> server-maintained) for this purpose. Michael Liben also liked this
> approach.

This can even be a virtual attribute for which the implementation can be
left to the vendor.  Should this include all sort of membership?  For
eg. static groups, member status through group nesting, dynamic groups...


> Simo Sorce proposed a control for server-side group expansion, and
> Michael Ströder suggested that an extended operation for asking specific
> membership questions would be better. Howard Chu suggested that any such
> operation would need a depth limit parameter.

Our experience shows that there needs to be a server side configuration
as well which can override the client request. If not, a malicious
client can create DoS attacks as the nesting operation is quite
expensive from a server side. A nested group objectclass definition
should also have a depth limit (Already suggested by Howard Chu).  There
should also be a parameter that defines if the server should chain a
request if there are groups from remote servers.

> Current situation
> =================
> 
> It seems to me that we now have these threads of development:
> 
> 1)	A new structural group class that can represent empty groups.
> 	This could go forward with the existing ambiguous member
> 	attribute or it could become the basis of a group
> 	representation with more carefully defined semantics using
> 	directMember.
> 
> 2)	A new auxiliary class and one or more attributes to represent
> 	groups that may contain other groups. For this to make much
> 	sense it would require the well-defined version of (1).
> 	
> 	In (1) and (2) I see the definitions of the attributes being
> 	the key, and would avoid requiring the use of the object
> 	classes to obtain the defined semantics.

Here is a suggestion:
groupMember
	This attribute value contains the DN of another group.
	( 2.16.840.1.113719.1.1.4.711 NAME 'groupMember'
	   SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

nestedConfig
	This bitmap contains the configuration options for a nested group.
	( 2.16.840.1.113719.1.1.4.712 NAME 'nestedConfig'
	  SYNTAX 1.3.6.1.4.1.1466.115.121.1.6)

excludedMember
	This attribute value contains the DNs that need to be excluded from
being a member of a group through nested evaluation. Thus, an entry is a
member of a nestedGroup only if it is listed in the member attribute of
any of the group objects in the nested hierarchy and it is not listed in
the excludedMember attribute
	( 2.16.840.1.113719.1.1.4.711 NAME 'excludedMember'
	   SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

nestedGroupAux
	This auxiliary class defines required attributes to represent groups
that may contain other groups.
	( 2.16.840.1.113719.1.1.6.1.91 NAME 'nestedGroupAux'
	  AUXILIARY
	  MAY ( groupMember $
		excludedMember $
		nestedConfig ) )



> 3)	A new control or extended operation so that a client can ask
> 	the server to do the heavy lifting involved with nested
> 	groups.
> 
> 4)	A new server-maintained attribute called memberOf to give an
> 	alternative way for clients to ask for membership information.
> 	AD already has such an attribute, and Pierangelo Masarati
> 	recently proposed one for OpenLDAP so there may be useful
> 	existing work to build on.
> 
> 5)	A document explaining why groupOfUniqueNames,
> 	uniqueMember and nameAndOptionalUID are bad, possibly leading
> 	to them being deprecated in the next revision of the core LDAP
> 	standards.
> 
> 
> I am willing to co-ordinate work on (1) and (2). Are there volunteers
> to take on the others?

I can co-ordinate (3) and (4).

--jaimon

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext