[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Dynamic group draft
Jaimon Jose wrote:
> "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.
BTW, I think I forgot to comment about this: nested groups are
explicitly forbidden based on (reasonable) performance issues, but
following search references requires an internal search anyway to fetch
referral objects. This seems contradictory, in the sense that the
possibility to chain distributed trees calls for the possibility to have
nested groups, since they face similar performance issues.
>> 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.
For the records, after being sloppy for quite some time, right now in
many places where an URI is used to configure internal searches (e.g.
SASL credentials mapping, and more) we strictly require the scheme to be
"ldap://"; to avoid confusion: things like specifying ldaps:// under the
expectation that credentials mapping has to be "secure" and so...
> 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.
This is an implicit requirement because the DN syntax has an equality
rule and thus no duplicate values are allowed by the data model.
>> 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 see Hallvard's point here: a search with a filter on dynamically
generated data requires dynamically data generation to occur __before__
candidate selection; BTW, it makes indexing nearly impossible. Any
implementation that allows to __search__ on dynamically generated
attributes would suffer from severe performance problems, and all
solutions I can see to mitigate the problem (like caching, and possibly
indexing cached attributes) seems to "open a can of worms", to be frank.
A request to read group membership is a totally different thing: the
group object is already located, and dynamic data expansion occurs while
__returning__ the results of the read.
>> 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.
As far as I understand, this point addresses clients that want to
__create__ a dynamic group, rather than clients that want to __use__
them. Dynamic groups should be transparent to clients when reading
group membership but, of course, if a client wants to create a dynamic
group it must make sure the related functionality is supported. Looking
the schema up actually looks like sort of a hack: should all related
schema items looked up? I believe the means suggested by Hallvard is
more conform to LDAP specs. But I agree there's need to discover if a
server implements dynamic groups.
I also agree a fine grained (naming context?) level is desirable. For
example, in OpenLDAP we would likely implement dynamic groups as an
overlay, which would typically affect only entries stored in a single
naming context. I know that's implementation specific (the overlay
could be global, though) but I think it may give you a glimpse of what
functionalities may need to be supported.
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext