Re: [ldapext] Summary of group discussion

["Keutel, Jochen" <[e-mail]>]

Hello Andrew,
   I'm definitely late in commenting this ... I just missed the 
discussion in September, sorry.

One thing I'd like to add: X.501 defines the X.500 access control 
schema. Esp. it defines:

ACIItem ::= SEQUENCE {
   identificationTag DirectoryString { ub-tag },
   precedence Precedence,
   authenticationLevel AuthenticationLevel,
   itemOrUserFirst CHOICE {
     itemFirst [0] SEQUENCE {
       protectedItems ProtectedItems,
       itemPermissions SET OF ItemPermission },
     userFirst [1] SEQUENCE {
       userClasses UserClasses,
       userPermissions SET OF UserPermission } } }

UserClasses ::= SEQUENCE {
   allUsers [0] NULL OPTIONAL,
   thisEntry [1] NULL OPTIONAL,
   name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
   userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
     -- dn component shall be the name of an
     -- entry of GroupOfUniqueNames
   subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL }

The referenced NameAndOptionalUID is defined in X.520:

NameAndOptionalUID ::= SEQUENCE {
   dn DistinguishedName,
   uid UniqueIdentifier OPTIONAL }

So here we have a unique identifier twice: Inside the groupOfUniqueNames 
and in the NameAndOptionalUID structure. Both are not used in the real 
world ... (at least I've never seen it).

The problem I see: Products using this ACI schema (esp. X.500 based 
products as e.g. Siemens DirX or CriticalPath) do only work if the 
userGroup component of UserClasses is really a groupOfuniqueNames. Of 
course you can put the DN of a groupOfNames or groupOfEntries or ... 
into this field - but ACI checking won't work.

So I see 2 points:

1. Shall X.501 be changed as well?

2. Shall this ACI issue be mentioned in your draft?

Best regards,  Jochen.






Andrew Findlay schrieb:
> draft-findlay-ldap-groupofentries-00.txt discussion summary 2007-09-24
> ======================================================================
> 
> On September 17th I introduced an I-D to create an LDAP group class
> that was capable of representing an empty group. The initial proposal
> was for the smallest possible change from the existing groupOfNames
> class.
> 
> Most people who joined the discussion on [e-mail] were broadly
> in support of allowing empty groups, though some thought that any
> changes away from the status quo were doomed to fail.
> 
> Howard Chu pointed out that groupOfUniqueNames is even worse than
> groupOfNames as the LDAP syntax for the nameAndOptionalUID attribute
> type cannot be parsed reliably.
> 
> Kurt Zeilenga provided much detailed editorial advice, and posed a
> question about how to handle groups where the DSA is unwilling or
> unable to return some or all member names.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Steven Legg proposed directMember and nestedGroups attributes, and
> Michael Ströder suggested that these might be a sufficient set to
> describe nested groups. I wondered whether nested groups should be split
> into those that could in turn have their own nested groups and those
> that could not, but Simo Sorce thought that people would never choose
> to use the more restrictive case. I was initially against dropping the
> original 'member' attribute, but Steven pointed out that having a new
> directMember attribute would allow people to define their own group
> classes and still take advantage of defined nesting semantics.
> 
> 
> 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.
> 
> 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?
> 
> Andrew

_______________________________________________
Ldapext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ldapext