Re: [ldapext] Dynamic group draft

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Various comments to the draft:


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.


The x-chain URL extension looks more generally useful than for just
groups.  I suggest you split it out to a separate draft.

Why doesn't x-chain follow referrals as well as 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.

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.


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.


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.


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.


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 security implications of allowing all kinds of URL extensions (and
other types of supported extensions for that matter) may be rather
complex.  Possibly servers should be restrictive in which extensions to
allow or honor.


Maybe some of the conflicting security concerns people have mentioned
could be eased by a dgPolicy attribute with implementation-defined
behavior.  E.g. it could specify whether or not to make use of
dgIdentity.  OTOH, this might just make security concerns even harder to
keep track of - including the problem of who may use which
server-defined dgPolicy.


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.


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.


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.

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.


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.

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.)

Not sure if it's worth implementing, or if someone who needs to search
for this should just know their directory and search for whatever their
dynamic groups search for.


The draft does not mention a third way to implement groups: a DN-valued
memberOf attribute in group members, with the DN(s) of group(s).  This
also solves the scalability problems of a static group with a gadzillion
entries, and it also allows clients to see which groups an object is a
member of.  (I've seen mention of memberOf before - I think it's a
Microsoft attribute, but I don't know its definition or if it has any
dynamic functionality attached.)


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.


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.


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.

(However, that does mean that if different naming contexts are held by
backends with different functionality, dynamic groups might be supported
in some but not all naming contexts in the server.  This sometimes
causes problems for clients.)

Anyway, what is the purpose of this requirement - i.e. what are the
consequences of ignoring it?

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?


6.1.1 (Access to resources in the directory) says:

   "The way to specify a dynamic ACL is currently implementation
   specific, as there is no common ACL definition for LDAP, and hence
   will be dealt with in a separate document or later (TO BE DONE)."

People have tried that before.  Don't promise it until it's done:-)


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.


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_.

-- 
Regards,
Hallvard

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