Re: [ldapext] Dynamic group draft

[Pierangelo Masarati <ando@sys-net.it>]

Haripriya S wrote:

> But I think I agree with you on the need to keep the identity
> flexible because there are some use-cases where dgIdentity may not
> make sense and could be a security violation. From that perspective,
> what you proposed in the previous mail seems to make sense.

OK, thanks.  Then, what about the inheritance issue (reported below for
clarity)?  That would definitely streamline the detection of dynamic
groups from an implementor's perspective (i.e. help implementations in a
LDAP'ish way).

Cheers, p.

   groupOfNames [STRUCTURAL] -------+- dynamicGroup
                                   /
                                  /     +- dynamicGroupAux
                                 /     /
   dynamicGroupAbs [ABSTRACT] --+-----+
                                 \     \
                                  \     +- dynamicGroupOfUniqueNamesAux
                                   \
   groupOfUniqueNames [STRUCTURAL] -+- dynamicGroupOfUniqueNames

Implementations would then simply check the presence of dynamicGroupAbs
in the inheritance tree of the group objectClass to determine if a group
has to be treated as dynamic in the sense of this draft.

For example, in OpenLDAP's ACL group jargon, that would be something like

access to *
        by group/<dynGroupClass>/memberQueryURL="<DN>" read

where <dynGroupClass> could be any of the classes introduced by the
draft.  The implementation should just check for inheritance from
"dynamicGroupAbs" (or whatever name you select for it) to allow a
IA5string valued member attribute, and treat it as an URL.


In case of modification to a member value that's dynamically generated,
noSuchAttribute would likely be returned.  Would it make any sense to
define a specific result code?  RFC4520 (Section 3.8) does not
explicitly require for the server any prior knowledge or assumption on
what the client understands to return an extended resultCode.


Finally, I remain a bit skeptical on the opportunity of recursion (or
nesting), which appears to be a desired feature (at least by Simo Sorce
and Pete Rowley).  However, I don't see any significant practical
objection, apart from potentially severe performance issues: during
compare/access control, without recursion only the "accessor" needs to
be fetched, and only if the filter is present in at least one URL.  If
recursion is allowed, even access checking and compare operations would
need an internal lookup to see if any of the objects matching the URLs
are groups themselves (either static or dynamic).  Set aside loop
detection/avoidance.
For this reason, I suggest to allow it in principle, but there should be
means to explicitly disable or enable it on a per-object basis,
depending on what is supposed to be the default behavior, without losing
compliance with this proposed standard.  For example, an optional
boolean-valued  "dgNesting" attribute could be added to the dynamic
group class, defaulting to FALSE if absent.  Or, for even more
granularity, an "x-nest" extension could be added to each URL whose
search allows nesting.  In fact, I see a lot of points of contact
between "x-chain" and nesting, from an implementor's viewpoint.



Right now, I'm considering the opportunity to implement this draft in
OpenLDAP.

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