Re: [ldapext] Dynamic group draft

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

Jaimon Jose writes:
>Hallvard B Furuseth wrote:
>(...)
>> 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.

I'm not sure I understand.  Do you mean compared to not having this
extension and always chaining if the search scope holds referrals to
other servers?  If so I guess that makes sense.  A no-chain extension
would fit that model better but it would be a pain to add it everywhere
if one wants to be sure to avoid chaining.

Anyway, I was thinking the other way, that a server would likely
normally not chain but this extension would make it do so.  And it's not
that I see any need in particular (I've rarely had need for LDAP URLs
myself), rather I imagine that once a server supports it and people make
use of it, they'll find other uses than with dynamic groups.
E.g. search for entries by giving a simple client an LDAP URL which
describes what to retrieve, and translate x-chain to a "chain" control
attached to the search request (draft-sermersheim-ldap-chaining-xx).

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

No.  First sentence of 4.5.3: "If the server was able to locate the
entry referred to by the baseObject (...)" it may return continuation
references.  However if the baseObject itself is in another server
that'll produce a referal (RFC 4511 4.1.10, 1st paragraph).

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

Taken from the ldapbis discussions.  IIRC the server may choose to
reject any request it wants to, unless your draft explicitly forbids
that.

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

Actually that's not what I was looking for.  Only a clarification of
whether it MUST or merely MAY support x-chain.  The point below takes
care of the case where it does not support it:

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

True enough.  Maybe I should have clarified, the section headers
"6. Dynamic Group Operations" and "7. Performance Considerations"
implies to me that the first describes what this feature does and the
next discusses some implications of that.  In that sense, "delayed
effect of modifications" looks like it should be mentioned in section 6.


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

I need to re-read the thread to figure out what you are saying here:-)

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

Except with x-chain.

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

Not sure what you mean here.  Strange interoperability problems if
someone figures out a way to support 'http:' URLs?

>> 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,

If that means you want to allow duplicates, the draft should say so

> wait for the member list to be completely generated
> before returning the result to client.

I don't see the difference here.  When reading the group object, the
complete PDU with all the 'member' attribute values can't be sent until
the object is complete.  When searching for members, the server can send
each member as soon as it is found.

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

I was thinking more of things like roleOccupant, not of how to
differentiate between static and dynamic members.  (As for x-static or
some other mechanism like the manageDSAit control, I need to think
before forming an opinion.)

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

I don't understand.  The memberQueryURL can generate unwanted entries,
but I don't see any ambiguity.

Or... one thing which does occur to me is that if a memberQueryURL is
being expanded at the same time as members are modified, the operation
may not be atomic: The generated member list might not reflect the state
which the directory had at any particular point of time.  (Unlike update
operations which are atomic with regard to individual entries.)

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

I don't understand why it "should work".  That is, I don't think it will
work with a simple implementation and it seems an unreasonable burden on
servers to require that they make it work.

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

'MAY' in the object class means the attribute MAY be present.

I'm not sure how to read "This attribute MAY be supported" - maybe the
server need not recognize it at all, in which case it can't have it
listed in the object class either.

Or maybe it'll simply ignore the attribute when expanding dynamic
groups.  Then a user (or client) who does not know if a particular
server supports dgIdentity, will get other results than he thought he
specified when he created a group.  The security implications of that
are bad.

So I think that one way or another, the server should reject an attempt
to add dgIdentity if it does not support it.  (That's a a generalization
of para 4.5.1, I guess.)

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

Well, I just don't know what that requirement means or why you added it.
As far as I can tell, if a client attempts to create a dynamic group
without first checking that the server supports them, then it breaks
this requirement.  Similarly, if the server does not announce what it
supports (with supportedExtension) then there is no point in supporting
dynamic groups since only broken clients can make use of them.

>(...)

-- 
Regards,
Hallvard

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