Re: [ldapext] Dynamic group draft

[Jaimon Jose <jjaimon@novell.com>]

Thanks for the detailed comment.  Please find my responses inline...

Hallvard B Furuseth wrote:
> Remove the "x-" prefix to the x-static attribute option and x-chain URL
> extension.  See RFC 4520 section 3.5: 'Options beginning with "x-" are
> for Private Use and cannot be registered.'  It doesn't say anything
> about "x-" URL extensions, but if that "x-" signifies anything it would
> be that it's a private extension.
>   
"x-" prefix to the x-static attribute option can be removed. 
> The x-chain URL extension looks more generally useful than for just
> groups.  I suggest you split it out to a separate draft.
>   
RFC 4516 does not talk about any specific extensions.  Do you see a need
for x-chain being a generic extensions? The main purpose of introducing
the extension is performance consideration where a client can
indefinitely wait if the search request follows referrals across wan links.
> Why doesn't x-chain follow referrals as well as continuation references?
>   
The operation being performed here is search ( internally ) and RFC
4511, section 4.5.3  states that search request will always return
continuation references.
> Are servers which support this draft required to support x-chain in URLs
> or not?  Section 4.2.1.1 says both that server "must" (lowercase) follow
> it and that servers MAY support it.  Section 7 says MUST - a requirement
> which belongs in section 6, not in a Performance Considerations section.
> Unless you rename section 7.
> If servers are required to honor x-chain when present, they can still
> complain unwillingToPerform for attempts to add such memberQueryURLs.
>   
That seems to be fair expectation.  The extension can be defined as
non-critical which means  servers are allowed to ignore the extension. 
I'll correct the sections and make it consistent.
> It may be worth emphasizing as a security matter that servers MUST NOT
> simply ignore critical URL extensions they do not support.  I have the
> impression that this is something people have been sloppy with.
>   
Right.  I will update the draft.
> The allowed time delay from Section 7.1 (Caching of Dynamic Members) has
> operational implications, not just performance implications.  Maybe you
> should turn it around a bit and say that servers may cache results of
> dynamic group lookup/generation, resulting in a time delay from when a
> member is modified until the change takes effect in groups.
>   
Caching can have additional implementation issues, performance,
security, etc.  The idea of section 7.1 one was just to give an
indication that "dynamic members" may be cached to improve performance. 
We can talk about possibilities and acceptable caching scenarios. 
> The dgIdentity cannot normally be used with x-chain, since the group
> object contains no credentials to bind with.  However the server _could_
> store credentials it can make use of somewhere.
>   
Right.  Again, this was left to the implementation to decide how to
authenticate to the remote server while chaining.
> People have mentioned that structural classes cannot subclass auxiliary
> classes.  Note also that groupOfNames and groupOfUniqueNames are defined
> with 'MUST (member/uniqueMember)', so if you inherit from these then
> people will usually need to add some dummy DN (e.g. "" or the DN of a
> non-existent object) as a static member just to satisfy that MUST.
>   
We are working on the proposal made by Pierangelo Masarati.  Creating
abstract classes and deriving dynamicGroupAux from this abstract classes
brings in its own complexity since this abstract class will not have
properties of group, but only dynamic group properties.  This may be an
issue if we associate dynamicGroupAux with any objects other than
groupOfNames and groupOfUniqueNames.
> Why are the scheme and host parts of memberQueryURLs ignored?  I think
> servers should at least be allowed to treat ftp://host/cn=foo??(cn=bar)
> as an error.  Or to make use of them with x-chain.
>   
The host is not necessary since the member expansion has to happen from
the server where the search is directed.   The scheme may be used if
groups can have members from outside of directory.  However, this might
bring in non-compliance if an implementation use dynamicGroups in their ACI.
> In addition to catching loops, the server must remove duplicates when
> returning the (unique)member attribute to clients.  An entry may be both
> a static and dynamic member, or come from several memberQueryURLs.
>   
True.  However, this may affect the performance and depending on
implementation, wait for the member list to be completely generated
before returning the result to client. 
>
> It could be useful to support an optional dgAttribute which names
> an attribute to use and generate instead of member/uniqueMember.
> Or two such attributes - one which says which attribute(s) to
> generate, one which says in which ones to find static members.
>   
"member" attribute is overloaded to support the existing clients.
member;x-static was introduced so that clients can ask for static
members alone.  This is debatable.

> An excludedMemberQueryURL attribute could be useful, which would exclude
> matches from memberQueryURL if it evaluated to True.  This:
>   memberQueryURL:         ldap:///cn=org??(&(a=foo)(!(b=bar)))
> is not equivalent to this:
>   memberQueryURL:         ldap:///cn=org??(a=foo)
>   excludedMemberQueryURL: ldap:///cn=org??(b=bar)
> since the former does not match when if (b=bar) evaluates to Undefined.
>   
"member" list of a DG could be ambiguous to an administrator at any
given point of time.  excludedMember was defined as a DN_SYNTAX to
overcome this ambiguity partially and to ensure that certain objects are
always excluded.  We will be introducing ambiguity in the excluded list
as well, if we define this as a URL. 
> Another approach would be to define a NOT-like filter which maps False
> and Undefined to True and True to False, or something which maps
> Undefined to False and leaves True and False alone.  I've missed that in
> some other circumstances.
>   
Possible.  Again the reason I mentioned above holds good.
>
> As far as I can tell, a search for (member=<some group's DN>) - "which
> groups is this object a member of?" - won't work with dynamic groups.
>   
It should work and the details are left to implementations.   For eg.  a
request to read groupMembership from an object should consider DGs as well.
> However a server could maintain a dgMember attribute as an extension:
> The server could either regularly search all dynamic groups and update
> an operational member attribute as needed.  Or it could intercept all
> update operations and check them against dynamic groups.  (Simplest
> would be to have this a dgMember subtype of member, but that doesn't
> work if one can specify which attribute is used in a dgAttribute like I
> suggested above.  If so the server would need to generate a subtype of
> that attribute instead, or something.)
>   
Yes, these options were considered.  We also debated on the impact in
performance for each of the steps mentioned above.  Finally, we decided
to leave this to the implementation.  However, looks like its worth
mentioning in the draft.

> 4.3 (member) and 4.4 (uniqueMember) refer to "Subclasses of this
> attribute".  Attributes have subtypes, not subclasses.  Though
> 'member;attribute option' can also be a subtype, I don't know if they
> should be considered or not - or if the draft ought to specify that or
> not.
>   
I'll make the change.

> 4.5 (dgIdentity):
>
>    "This attribute MAY be supported, and represents the identity the
>    server will use for processing the memberQueryURL."
>
> Move that sentence to near the top of this section.
>
> If the attribute is not supported, should it be present in the schema
> and in the object classes' MAY lists?  Marked OBSOLETE, maybe?
> If yes, should an attempt to add it result in an error?  It would be
> misleading if one adds the attribute but it has no effect.
>   
I'm not sure I understood the above concerns completely.  As mentioned,
the idea was to get consistent result irrespective of client's bind
identity.  Again, this has to be left the owner of the group and so, the
attribute was marked as a MAY attribute on the objectclass.

> Section 5 (Advertisement of support for dynamic groups) says:
>
>    "If the dynamic groups schema is not present on an LDAP server, it
>    MUST be assumed that the dynamic groups feature is not supported."
>
> Which schema in the LDAP server?  A server can hold several naming
> contexts controlled by different schemas.
>
> The standard way to announce extensions is to put the extension's OID in
> supportedExtension in the root DSE.  See RFC 4512 section 5.1 and 5.1.4.
>   
You are right.  This will be updated.

> And how do I implement it?  My client MUST NOT attempt to make use of
> dynamic group features without first checking that they are supported?
> What if it attempts to check but does not find the schema (or
> supportedExtension)?  Should a server which does support the
> objectClasses attribute (or supportedExtension) refrain from supporting
> dynamic groups?
>   
I'm not sure I understood this. 
> 6.1.3 ('Is Member Of' functionality):
>
>    "As of this writing, no other
>    matching rules exist for the distinguished name syntax, thus no
>    requirements beyond equalityMatch are given here."
>
> I think component matching rules (RFC 3687) are relevant, but I still
> haven't read the thing.
>   
I need to read more about this.

> 8 (Security Considerations):
>
>    "The administrator could view the memberships and make sure
>    that anybody who is not supposed to be a member of a group is added
>    to the excludedMember list."
>
> Well, since the group is dynamic he can't exactly make _sure_.
>   
:-).  I will reword this.

Thanks for the valuable feedbacks. I'll update the drafts for next
submission.  I'll be happy to hear from you again.

--jaimon

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