Subject: [ldapext] Dynamic group draft

From: Howard Chu <[email-masked]>
Date: Wed, 07 Feb 2007 16:21:56 -0800

http://www.ietf.org/internet-drafts/draft-haripriya-dynamicgroup-02.txt

It's funny that this has come up since we've been having discussions of 
these same points on the OpenLDAP-Devel mailing list recently. I hadn't 
seen any prior versions of this draft before, can you point me to a 
forum where it had been discussed?

Some comments/questions about this draft, mostly trivial:

While I don't think there was ever a formal spec published, a lot of 
vendors already use the memberURL attribute that Netscape defined for 
their default dynamic group implementation. Why did you feel it was 
necessary to define a new "memberQueryURL" attribute that is essentially 
identical in meaning to memberURL?

There are some obvious errors in this document, you list the 
uniqueMember attribute with OID 2.5.4.32 inheriting from 
distinguishedName, but 2.5.4.32 is actually the owner attribute. 
uniqueMember is 2.5.4.50 and cannot inherit from distinguishedName since 
it is of NameAndOptionalUUID syntax, not distinguishedName syntax.

There's a lack of symmetry here - "excludedMember" is used for both 
member and uniqueMember but it shouldn't be since the two syntaxes are 
not the same. You need an excludedUniqueMember attribute to provide the 
relevant functionality.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Howard Chu <[email-masked]>
Date: Wed, 07 Feb 2007 17:49:02 -0800

Howard Chu wrote:
> necessary to define a new "memberQueryURL" attribute that is 
> essentially identical in meaning to memberURL?
>
Actually looking over our implementation in OpenLDAP, I guess that 
defining a new attribute is probably a good move. But it should inherit 
from labeledURI, to make its semantics more obvious.

---

From: "Haripriya S" <[email-masked]>
Date: Thu, 08 Feb 2007 03:38:22 -0700

Hi,

The original version of the draft was named draft-haripriya-dynamicgroup-00.txt was submitted in November 2001, and was posted to the the ldapext mailing list. (The list was not very active during that time frame). Some feedback was received (mostly out-of-band)  and a version 1 of the draft was also submitted. It expired subsequently and is being reissued now.

You can find the previous posting and draft versions 0 and 1 at
http://www1.ietf.org/mail-archive/web-old/ietf-announce-old/Current/msg15441.html
http://www.potaroo.net/ietf/all-ids/draft-haripriya-dynamicgroup-00.txt
http://tools.ietf.org/html/draft-haripriya-dynamicgroup-01

Thanks,
Haripriya S.
 
>>> Howard Chu <[email-masked]> 02/08/07 5:51 AM >>> 
http://www.ietf.org/internet- drafts/draft- haripriya- dynamicgroup- 02.txt

It's funny that this has come up since we've been having discussions of 
these same points on the OpenLDAP- Devel mailing list recently. I hadn't 
seen any prior versions of this draft before, can you point me to a 
forum where it had been discussed?

---

From: "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
Date: Thu, 8 Feb 2007 11:23:24 -0600

Hi Howard,

Could you explain your OpenLDAP implementaon comments a bit further?  I
too would be conderned about proposing new "dynamic group" schema
elements.  I'm wondering if an "implememtation" issue in OpenLDAP is
enough reason to prose new schema elements.

Bob

> -----Original Message-----
> From: Howard Chu [mailto:[email-masked]] 
> Sent: Wednesday, February 07, 2007 5:49 PM
> To: Ldapext; Jim Sermersheim
> Subject: Re: [ldapext] Dynamic group draft
> 
> Howard Chu wrote:

---

From: Jaimon Jose <[email-masked]>
Date: Thu, 08 Feb 2007 23:02:45 +0530

Howard,
thanks for the comments.  I couldn't locate any documents on openldap
implementation of dynamic group.  Appreciate if you can forward any
reference to this.

Howard Chu wrote:
> Why did you feel it was necessary to define a new "memberQueryURL"
> attribute that is essentially identical in meaning to memberURL?
One reason is the extensibility of the attribute value.  As I remember,
memberURL can only contain a base, scope and the search filter.  The
searches are limited to the same LDAP server.  memberQueryURL attribute
can contain an additional x-chain extension.  LDAP server will chain the
request in a distributed environment if this extension is present. 
> uniqueMember is 2.5.4.50 and cannot inherit from distinguishedName
> since it is of NameAndOptionalUUID syntax, not distinguishedName syntax.
Thanks for pointing this out.  I will correct them.
> not the same. You need an excludedUniqueMember attribute to provide
> the relevant functionality.
excludedMember is a list of DNs that need to be excluded from the
returned result set.  This disparity was caused because the original
implementation returned both dynamic and static member list as
"member".  However, do you really see a need for two attributes?

Thanks
--jaimon

---

From: Howard Chu <[email-masked]>
Date: Thu, 08 Feb 2007 15:16:08 -0800

> implementation of dynamic group.  Appreciate if you can forward any
We've always referred users to the original Netscape documentation, 
since that's where our definitions came from. But for the purposes of 
slapd access control, we've always allowed groups to use arbitrary 
schema.  See our slapd.access( 5 ) manpage. Basically, our syntax is
    access to foo
       by group[/objectclass[/attributename]] = <groupDN> ...

The defaults are groupOfNames and member, but you can use any object 
with any attribute that uses DN or nameAndOptionalUid syntax. This 
covers the static group support.

For a dynamic group, the same config syntax applies, but the objectclass 
and attributename obviously must be provided explicitly. The trigger for 
dynamic group behavior is that the specified attribute must be a subtype 
of labeledURI. This requirement is also spelled out in the slapd.access( 
5 ) manpage.

Ideally I would have said "the specified attribute has URI syntax" but 
obviously there is no such syntax in the base LDAP specification. 
(Though I believe there ought to be. One of the great strengths of 
X.500/ASN.1 is the self-describing nature of data; defining everything 
as IA5string or some other generic string syntax as LDAP has 
traditionally done totally neuters the system. But that's a different 
conversation...)

The original Netscape memberURL definition just uses IA5string syntax,  
but the dyngroup.schema file that we provide with OpenLDAP defines it as 
a subtype of labeledURI so that it will work with our ACL engine.

Re-reading this draft prompted me to revisit some other aspects of our 
implementation, which makes me think it's even more necessary to define 
new schema elements and abandon the current Netscape definitions. I.e., 
the Netscape definition was broken from day one; it is inherently 
impossible for a LDAPv3-compliant server to implement both their 
published definition and their deployed usage, only one or the other can 
actually be supported.  I've documented this problem here:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4835

> request in a distributed environment if this extension is present. 

Since you're only talking about x-chain as an extension field in a URL, 
and such a field could appear legally in any URL, I don't think this is 
a problem or a compelling reason. However, for the reasons I alluded to 
above, I believe we do need a new attribute, and it should be a subtype 
of labeledURI.

> "member".  However, do you really see a need for two attributes?

Frankly I've never seen anybody using uniqueMember for its intended 
purpose. But it seems to me that if you are using uniqueMember, with a 
syntax of nameAndOptionalUID, then your set of exclusions must also use 
nameAndOptionalUID syntax.

But now that I think of it, evaluating the URL will perform a search 
which can only return actual DNs, so perhaps just a single exclusion 
attribute of DN syntax is fine. But that raises the question of whether 
defining a dynamic version of this group is actually a safe or valid 
thing to do. Only the static uniqueMember attributes will actually have 
the "unique" semantics. If anybody was actually relying on the DN 
uniqueness characteristic here, they would be in for disappointment at 
least, but most likely a security breach. IMO use of dynamic behavior 
with groupOfUniqueNames should be prohibited for these reasons.

---

From: Pierangelo Masarati <[email-masked]>
Date: Fri, 09 Feb 2007 22:14:08 +0100

> forum where it had been discussed?

One point that puzzles me is a security concern, which was extensively
discussed about OpenLDAP's slapo-dynlist(5) overlay

<http://www.openldap.org/lists/openldap-devel/200701/msg00038.html>

which basically deals with the identity that must be used to perform the
internal search to collect the dynamic group.  In dynlist's case things
are complicated by the fact that attributes of the entries matching the
search need to be collected, but the problem is the same.

If I understand that draft correctly, internal searches are either
performed anonymously, or, if dgIdentity is present, using that
identity.  The rationale is that using any other identity, and
significantly that of the operation accessing the dynamic group, would
lead to identity-dependent group membership.

I understand data uniformity in some cases may be an issue, but it seems
to me (as I argumented in that discussion) that this could either (a)
break security or (b) lead to other inconsistencies; for example:

(a) Using dgIdentity could break security if a user with privileges that
do not allow disclosure of the existence of a certain DN reads or
compares a dynamic group that discloses that information.

(b) Using anonymous, or even dgIdentity, could lead to inconsistencies
if a user is granted permission access the results of a search defined
as the memberQueryURL of a dynamic group, but neither anonymous nor the
dgIdentity have such privileges (this is a minor issue, though).

For this reason, although we planned to introduce something like
dgIdentity in slapo-dynlist(5), I believe that a safer and more
consistent solution would be to change the specification so that:

1) in case a dgIdentity is defined, it MUST be used to perform the
internal operations; if it's set to the empty DN (""), internal
operations are performed anonymously.  Implementations may use access
control to determine whether a user is allowed to access, and thus
assume, dgIdentity to perform the internal operations;

2) otherwise searches and operations are performed with the user's identity

In slapo-dynlist(5) we also discussed the opportunity to introduce some
sort of authorization (along the lines of the authzFrom operational
attribute used for authorization) to determine whether a certain user is
allowed to perform internal operations using OpenLDAP's equivalent of
the dgIdentity.  Nothing of this is implemented yet.

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:    [email-masked]
------------------------------------------

---

From: Pierangelo Masarati <[email-masked]>
Date: Sat, 10 Feb 2007 11:53:27 +0100

> Some comments/questions about this draft, mostly trivial:

Additional comments: "dgIdentity" is used in objectClass definition, but
it is actually defined as "identity" in the attributes section.  I guess
the intended definition is "dgIdentity".

BTW, would prefixing "memberQueryURL" and "excludedMember" with "dg" be
an option?

AUXILIARY classes dynamicGroupAux and dynamicGroupOfUniqueNamesAux
cannot respectively inherit from groupOfNames and groupOfUniqueNames
since the latter are STRUCTURAL.

p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: Pierangelo Masarati <[email-masked]>
Date: Sat, 10 Feb 2007 12:30:46 +0100

>> Some comments/questions about this draft, mostly trivial:

Another comment: the effect of the "x-static" option in OpenLDAP's
slapo-dynlist(5) is obtained by using the manageDSAit control (RFC
3296), which prevents expansion of the dynamic members.  This mimics the
behavior of LDAP when accessing named reference objects.  I wonder what
approach is more LDAP'ish (overloading of manageDSAit is explicitly
considered in RFC 3296) and more favorable to generic clients.

p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: "Haripriya S" <[email-masked]>
Date: Sat, 10 Feb 2007 06:02:43 -0700

One of the use-cases of dynamic group is to set a dynamic group as an ACL Trustee for a resource. For use in this situation, using the user's identity could be a problem with respect to both security and consistency. Imagine a case where a deny ACL is set using the dynamic group as a trustee with the expectation that the members of the dynamic group will match that. Now if the members get limited by the user's search rights, then an access could be granted where it should have not been. Using a  separate identity (eg. dgIdentity) builds consistency and predictability into the dynamic group member list.

imho the members of a dynamic group should be based on the intention of the administrator - not based on the rights of the user. However who can read the dynamic group attributes can be limited by the ACLs on the DG object.

Thanks and Regards,
Haripriya
 
>>> Pierangelo Masarati <[email-masked]> 02/10/07 2:44 AM >>> 

One point that puzzles me is a security concern, which was extensively
discussed about OpenLDAP's slapo-  dynlist(5) overlay

<http://www.openldap.org/lists/openldap-  devel/200701/msg00038.html>

lead to identity-  dependent group membership.

For this reason, although we planned to introduce something like
dgIdentity in slapo-  dynlist(5), I believe that a safer and more
consistent solution would be to change the specification so that:

In slapo-  dynlist(5) we also discussed the opportunity to introduce some

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

---

From: "Pierangelo Masarati" <[email-masked]>
Date: Sun, 11 Feb 2007 10:46:19 +0100 (CET)

> One of the use-cases of dynamic group is to set a dynamic group as an ACL
> Trustee for a resource. For use in this situation, using the user's
> identity could be a problem with respect to both security and consistency.
> Imagine a case where a deny ACL is set using the dynamic group as a
> trustee with the expectation that the members of the dynamic group will
> match that. Now if the members get limited by the user's search rights,
> then an access could be granted where it should have not been. Using a
> separate identity (eg. dgIdentity) builds consistency and predictability
> into the dynamic group member list.
>
> imho the members of a dynamic group should be based on the intention of
> the administrator - not based on the rights of the user. However who can
> read the dynamic group attributes can be limited by the ACLs on the DG
> object.

I get the point, and I understand that your reasons are valid, but I think
the two points we're trying to make are different.

Your point makes sense when the group is being used for access control. 
For example, in OpenLDAP, under some circumstances, internal searches are
performed as the rootdn, since they are intended to collect data for
special purposes and not to operate on them on behalf of the client.  This
is the case, for example, of ACL checking: if internal lookups for ACL
checking were performed with the client's identity, there would be a
chicken and egg problem, where client's access to data used for ACL
checking would need to be checked.

But the draft, as it is now, seems to requirethat  __any__ access to the
internal data be performed as dgIdentity, including direct access, like
listing the dynamic group member.  I believe this should be an option; the
draft should allow the owner of the dynamic group to decide how users can
access the data.  I don't mind if the default is dgIdentity, or anonymous
or the client's identity, but there should be the possibility to use both
(anonymous can be a special case of dgIdentity with the empty DN).

Cheers, p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: Pierangelo Masarati <[email-masked]>
Date: Sun, 11 Feb 2007 23:39:22 +0100

Haripriya S wrote:
> One of the use-cases of dynamic group is to set a dynamic group as an
> ACL Trustee for a resource. For use in this situation, using the
> user's identity could be a problem with respect to both security and
> consistency. Imagine a case where a deny ACL is set using the dynamic
> group as a trustee with the expectation that the members of the
> dynamic group will match that. Now if the members get limited by the
> user's search rights, then an access could be granted where it should
> have not been. Using a  separate identity (eg. dgIdentity) builds
> consistency and predictability into the dynamic group member list.
> 
> imho the members of a dynamic group should be based on the intention
> of the administrator - not based on the rights of the user. However
> who can read the dynamic group attributes can be limited by the ACLs
> on the DG object.

Sorry for bothering again, but according to your above answer, it may
appear that you infer a (possibly unrelated and desirable) capability
from the need to work an implementation specific access control data
model around.  This would be a poor way to define a potential standard.

I admit your example definitely makes sense, but it relies on a number
of issues that I'd treat as bugs of the underlying implementation,
rather than as advantages for administrators:

- the access data model is based on a grant/deny model, which is
confusing and error prone (if grants and denies have to be explicitated,
it's hard to tell what's the default that's going to apply to what's
left out of grants and denies)

- the access data model could use the operation's identity to perform
information harvesting in a non-consistent manner, so you need to
explicitly force the use of a given identity

- the data consistency and security workaround would defeat the purpose
of a dynamic group

The solution you propose, namely delocalizing access information
otherwise you would incur in limitations because in an implementation
it's based on a localized data model seems to me quite counterintuitive
and prone to further errors.  In fact, administrators could be led into
believing that access is governed by local data, while there are items,
like dynamic groups, that can work those rules around.

Also, you state that further access checking on the contents of
dynamically generated membership may prevent disclosure in case of
direct lookups, and that's right, but this means that rules to check
access to dynamically generated data must duplicate data specific rules.

For example:

object A
    grant dgIdentity read access
    deny all any privilege, including disclose

object B: dynamic group, with query matching object A
    grant all read privilege

any user is not even allowed to directly discover the existence of
object A; but object B allows any user to discover that existence.
According to your proposed definition of dynamic group, the dynamic
group would need a rule like

object B: dynamic group, with query matching object A
    grant all read privilege
    deny all any privilege on object B

thus defeating the purpose of a dynamic group, if per-dynamically
generated value access needs to be specified.

On the contrary, if you allow implementations to differentiate the
identity used for information harvesting based on the usage, access
information can remain localized while preserving access integrity.

The dgIdentity feature you desire, which may be of help to
administrators in other cases as well, could be added as an option (or,
which would be my second choice, data harvesting should be optionally
allowed to be performed with the operation identity).

Cheers, p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: Pete Rowley <[email-masked]>
Date: Sun, 11 Feb 2007 20:38:02 -0800

> http://www.ietf.org/internet-drafts/draft-haripriya-dynamicgroup-02.txt

I am pretty concerned that introducing a new group type might simply 
further complicate the current LDAP group mess.  IMHO any addition to 
the LDAP grouping story should unify grouping mechanisms such that 
directly managed groups work the same way as dynamic groups from a 
non-administrative client perspective (which admittedly this draft does 
attempt), that nested groups be explicitly supported (because the 
management reality is that they are required), and that the server is 
tasked to do the work required for group membership so that the client 
is left with simple tasks to perform normal group operations such as 
enumeration and membership testing, and that those tasks are exactly the 
same no matter which type of group is being examined.  LDAP groups (both 
static and dynamic) are far too focused on the requirements for 
server-side access control and provide very little in the way of support 
to clients for use as a general purpose grouping mechanism - most 
notably because those two grouping methods work in completely different 
ways.  IOW "LDAP group" ideally should mean one thing to a client even 
if to a server it may be many sub-types. Necessarily, this would 
probably mean a "clean cut" from the current grouping mechanisms, and 
yes that makes this an unlikely event, but I actually think this is 
necessary if we are ever to get a coherent, usable, and scalable LDAP 
group story.

These were actually some of the requirements that fed into the 
FDS/Sun/Netscape roles feature, which I reference only as an example of 
an approach.  In that scheme clients performing non-administrative tasks 
have an exceptionally easy time working with roles, enumeration is a 
search, group membership tests are a compare, there is no distinction 
between role types at this level, everything is a DN, and yet managed, 
dynamic, nested, and TBD can all be supported by the client with a 
single group implementation - and all is subject to normal access 
controls for the DIT. The server OTOH is doing quite a bit of work to 
make this all happen, and that, IMHO, is how it should be.

Ultimately, I'd rather see nothing happen than another grouping scheme 
that adds to the client load without showing a reasonable path to 
grouping nirvana where current methods can be deprecated (or at least 
not considered for future client dev).

-- 
Pete

---

From: simo <[email-masked]>
Date: Mon, 12 Feb 2007 02:00:20 -0500

> not considered for future client dev).

I rarely comment, if at all, on this list, but I have to say I agree
100% with Pete's analysis and conclusions.
KISS for clients is a must.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: [email-masked]
http://samba.org

---

From: Pierangelo Masarati <[email-masked]>
Date: Mon, 12 Feb 2007 09:30:25 +0100

> not considered for future client dev).

Well, for well-behaved clients I think this draft goes in the right
direction.  However, it depends whether you include the group manager
among the users or the administrators: for the group manager, complexity
will increase, while for other users it should remain exactly the same,
and the dynamic generation of part of the members should go unnoticed.

- existing static groups can be converted to dynamic by adding the
AUXILIARY class
- new groups can either be created as static plus the AUXILIARY class,
or dynamic groups.  Well-behaved clients allow filtering for the static
class since the dynamic one inherits from it
- adding/deleting members works as usual, treating them as static (a
notable exception is removing a dynamic member, which causes an error
and should actually lead to excluding the member)
- member exclusion before returning members and while comparing, and
things like that are dealt with by the implementation, so it's totally
transparent to the client (either normal user or administrator)

With respect to nested grouping, that's an interesting point.  I would
allow it for implementations that can guarantee that loops are
impossible.  I understand this would need to be somehow advertised so
that clients do not add dynamic group members to a dynamic group under
the assumption they will be expanded.

I don't think just dropping existing static groups and replacing them
with a new dynamic group would be an option, since there's too many
clients out there relying on groupOfNames and company; I don't thing
redefining it to allow dynamic groups would be an option either.

Cheers, p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: Pete Rowley <[email-masked]>
Date: Mon, 12 Feb 2007 01:20:17 -0800

Pierangelo Masarati wrote:
> will increase,
When I say administrator I mean whomever has administrative rights over 
the group in this instance i.e the group manager
>  while for other users it should remain exactly the same,
Yes.  However, static groups do not scale very well - in fact one of the 
motivations for dynamic groups was the deficiency of static group 
scaling. In short. put a few tens of thousands of members in a static 
group and things get rather slow, both client and server side. So while 
static group emulation is tempting from a conformance to current 
practice point of view, it actually exacerbates the problem.

> and should actually lead to excluding the member)
right, which breaks the existing model and existing clients.
> transparent to the client (either normal user or administrator)
that's a good thing (TM)
> impossible.
Implicit in a nested group specification would have to be loop detection 
- the embodiment of that would be implementation specific. I do not 
believe that loop detection is impossible, I believe it may be harsh for 
some implementations/deployments but not impossible. Though I welcome 
specific examples here since distributed DITS are not my every day food.
>   I understand this would need to be somehow advertised so
Server options for group expansion are a recipe for confused clients and 
security mishaps. It is ok to have those kind of requirements if the 
assumption is that groups are only ever used internally to the server, 
but the fact is that groups are used for external reasons by clients. If 
that were not a usage they should never have been published as a general 
purpose grouping mechanism. Options based on server ability are bad when 
it comes to such fundamental facilities - the server just needs to do it.
> redefining it to allow dynamic groups would be an option either.
I understand your reservation on that, it isn't pretty.

-- 
Pete

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 12 Feb 2007 17:08:45 +0100

Howard Chu wrote:
> memberQueryURL (...) should inherit from labeledURI, to make its
> semantics more obvious.

No.  You should normally not inherit from an attribute which is intended
to be present in directory entries.  In particular when the attributes
are used for quite different purposes (typically an URL for humans to
click on, vs. LDAP-related info).

Otherwise people who search for labeledURI can receive unwanted matches
for memberQueryURL (though that looks unlikely except for presence match
in this case), a labeledURI index will be filled up with useless
memberQueryURL data, and a search which requests attribute labeledURI
will receive memberQueryURL as well.

And they do not have the same syntax anyway.  memberQueryURL does not
allow a general URI, nor the label part of labeledURI.

-- 
Regards,
Hallvard

---

From: Howard Chu <[email-masked]>
Date: Mon, 12 Feb 2007 08:42:16 -0800

> allow a general URI, nor the label part of labeledURI.

Fair enough. That just brings me back to my earlier point that there 
should be an actual syntax defined for URLs.

---

From: Jaimon Jose <[email-masked]>
Date: Tue, 13 Feb 2007 12:23:45 +0530

> allow a general URI, nor the label part of labeledURI.

True.  memberQueryURL is intended to be RFC2255 ( now RFC4516 )
compliant.  I do understand that memberQueryURL does not fall under
labeledURI.  I'm not quite clear on the comment "memberQueryURL does not
allow a general URI"

--jaimon

---

From: Jaimon Jose <[email-masked]>
Date: Tue, 13 Feb 2007 12:26:23 +0530

> should be an actual syntax defined for URLs.

Thinking more about this, I think, I like the idea.  If I have a large
number of URLs stored, my searches can be more efficient if I can index
on each of the URL elements.

--jaimon

---

From: Jaimon Jose <[email-masked]>
Date: Tue, 13 Feb 2007 12:46:13 +0530

> the intended definition is "dgIdentity".

Section #4.5 refers this attribute as dgIdentity.  The second paragraph
in this section, talks about "identity values" which should have been
"dgIdentity values" .   Did I miss out something?
> BTW, would prefixing "memberQueryURL" and "excludedMember" with "dg" be
MAY be a good idea to have consistency in attribute naming with respect
to the features where the attributes are used.  As I recall, this is not
used in all cases.
> since the latter are STRUCTURAL.

The idea of inheriting from groupOfnames and groupOfUniqueNames is to
have the group properties in addition to dynamicGroup properties. 
Certain implementations seem to allow that.   I'm personally not in
favor of copying the group properties to the auxiliary class.  Lack of
these properties will introduce a constraint that,  only group objects
can be marked as dynamic group. 

--jaimon

---

From: Howard Chu <[email-masked]>
Date: Mon, 12 Feb 2007 23:38:29 -0800

Jaimon Jose wrote:
> Certain implementations seem to allow that. 

Those implementations are clearly broken then. The data model is quite 
explicit; this is stated in RFC4512 section 2.4.3:
    Auxiliary object classes cannot subclass structural object classes.

>   I'm personally not in

You can take the approach that IBM did...

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzahy/rzahygpattr.htm

Clearly you must not write a spec that doesn't conform to RFC4512.

---

From: Pierangelo Masarati <[email-masked]>
Date: Tue, 13 Feb 2007 09:14:21 +0100

> "dgIdentity values" .   Did I miss out something?

In Section #4.5, the title refers to this attribute as dgIdentity, but
in the subsequent RFC 4512 definition I read identity for the NAME
field.  I suspect a typo there.

> can be marked as dynamic group. 

I concur with Howard's answer.  As a side note, by exploiting LDAP's
object orientation, you could create an abstract class dynamicGroupAbs,
then derive dynamicGroup from both groupOfNames and dynamicGroupAbs, and
dynamicGroupAux from dynamicGroupAbs only.

the *UniqueNames* variants could be derived from the same class, thus
having a single, strong characterization of dynamic groups (at least,
for those clients that speak inheritance) and some advantages for
implementors as well, which could delegate to the inheritance
capabilities of their software the handling of the variety of
combinations of dynamic groups.

See the graph below:

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

The same should have occurred from the beginning with the groupOfNames
class; then, all group classes could have inherited from a common,
abstract notion of group.

p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: "Haripriya S" <[email-masked]>
Date: Thu, 15 Feb 2007 05:23:07 -0700

I understand what you are saying here. But I was not specifically referring to implementation-specific ACL model inside the LDAP server when I mentioned that example. So the problems you list may be valid if there exists an LDAP implementation with these issues, but I was not referring to or know of any.

What I was referring to instead was a case in which applications may use a dynamic group as an access trustee and may implement an 'external' access control model on top of that. Take the case of NFSv4 ACEs, CIFS ACLs (they allow deny lists) or other similar applications implemented using LDAP objects. I was referring to cases like that where the predictability of the members in the list is essential for the application irrespective of the authenticated identity.

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.

Thanks and Regards,
Haripriya

>>> Pierangelo Masarati <[email-masked]> 02/12/07 4:09 AM >>> 
Haripriya S wrote:
> One of the use- cases of dynamic group is to set a dynamic group as an

-  the access data model could use the operation's identity to perform
information harvesting in a non- consistent manner, so you need to
explicitly force the use of a given identity

For example:

object A

thus defeating the purpose of a dynamic group, if per- dynamically
generated value access needs to be specified.

Cheers, p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: Pierangelo Masarati <[email-masked]>
Date: Sat, 17 Feb 2007 16:13:34 +0100

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 20 Feb 2007 13:21:04 +0100

Jaimon Jose writes:
>> (...)  memberQueryURL does not
> (...)  I'm not quite clear on the comment "memberQueryURL does not
> allow a general URI"

Sorry, I lost this thread a bit.  Answer: I had a confused and outdated
idea of URI/URL/URNs.

-- 
Regards,
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 20 Feb 2007 16:54:41 +0100

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

---

From: Jaimon Jose <[email-masked]>
Date: Wed, 21 Feb 2007 00:41:20 +0530

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

> be that it's a private extension.
"x-" prefix to the x-static attribute option can be removed. 
> 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.
> 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.
> impression that this is something people have been sloppy with.
Right.  I will update the draft.
> 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. 
> 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.
> 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.
> 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.
> 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. 
> 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.

> 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. 
> some other circumstances.
Possible.  Again the reason I mentioned above holds good.
> 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.
> 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.

> should be considered or not - or if the draft ought to specify that or
I'll make the change.

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

> supportedExtension in the root DSE.  See RFC 4512 section 5.1 and 5.1.4.
You are right.  This will be updated.

> objectClasses attribute (or supportedExtension) refrain from supporting
I'm not sure I understood this. 
> I think component matching rules (RFC 3687) are relevant, but I still
I need to read more about this.

> 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

---

From: Pierangelo Masarati <[email-masked]>
Date: Tue, 20 Feb 2007 21:33:50 +0100

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

> 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

This is an implicit requirement because the DN syntax has an equality
rule and thus no duplicate values are allowed by the data model.

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

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 20 Feb 2007 21:47:00 +0100

Jaimon Jose writes:
>(...)
> 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).

> 4511, section 4.5.3  states that search request will always return

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

> 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

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

> groupOfNames and groupOfUniqueNames.

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

> 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

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

> implementation,

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

> wait for the member list to be completely generated

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.

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

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

> (...)

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.

> (...)

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

>> (...)

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 21 Feb 2007 19:09:01 +0100

> attached to the search request (draft-sermersheim-ldap-chaining-xx).

Sorry, I was confusing myself.  Of course an URL extension used in
clients is not the same as what we call "chaining" in a server.
E.g. a client which reads data specified by an LDAP URL could prefer
either chaining (if supported) or referrals from the server when there
is no URL extension.

Um.  Perhaps it'd be better to call the URL extension 'remote' or
something, in case someone else would make the same mistake.
I.e. "The server will not follow continuation references unless the URL
specifies with ?remote that there may be remote entries."

-- 
Regards,
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 21 Feb 2007 19:49:29 +0100

> on each of the URL elements.

You need special matching rules too for that, and support for indexing
of extended filters like "(memberQueryURL:LDAPURLScopeMatch:=sub)".

Alternatively, you could define a "normalized" form of LDAP URLs where
all '?'s are present, and then a sort of substring match, so
(memberQueryURL=ldap:///c=foo??*) would match 'ldap:///c=foo'.
A '*' should only match one URL component.

BTW, keep in mind that if the draft makes use a new syntax and new
matching rules, it can't be implemented (correctly) unless the syntax
and matching rules are implemented as well.  So it might be a bad idea
to make them very complicated.

Still, with a really useful draft which pushes for their implementation,
there may be a real hope that such a syntax will get widely implemented,
so we can make use of it for other URLs too:-)

-- 
Regards,
Hallvard

---

From: Pierangelo Masarati <[email-masked]>
Date: Wed, 21 Feb 2007 20:06:03 +0100

> so we can make use of it for other URLs too:-)

An (LDAP) URL is a composite datum, so a syntax for the definition of an
URL-valued attribute should definitely rely on separate syntax
definitions for each component, according to RFC4516.  The DN portion is
a clear example.

I would have no objection to defining a URL syntax; this would really
avoid issues like syntax errors detection at run-time, resulting in
incorrect handling of URLs that would essentially go unnoticed.  Also,
it would be much more efficient to normalize URLs once for all, easing
the parse phase.  URL-valued attributes would be based on this syntax,
and, of course, they would have nothing to do with the current
labeledURI attribute.

However, I believe this should go in a separate draft.  The fact that a
brand new syntax is used in the dynamic group draft would not be a
weakness in my opinion: regular (I mean: read) clients wouldn't have to
deal with it.

p.

p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 21 Feb 2007 20:21:21 +0100

Pierangelo Masarati writes:
> them.

Ah.  Yes, that's what I meant.  I was thinking "make use of" as a client
user.  Also if you don't create them you can't use them.  You can create
entries by building the LDAP database offline, but the LDAP standard
does not cover that so it's simpler to formally think of everything as
created by clients.

A few other points:

The Compare and Search operations match subtypes.  If subtypes of
"member" and "uniqueMember" are not considered for static members,
then Compare(base DN, "member", candidate DN) and Search with
filter "(member=candidate DN)" are incorrect membership checks.

Maybe you should leave the behavior of static groups implementation-
defined and merely suggest a recommended practice:

A number of servers already implement groups based on member or
uniqueMember.  Since such groups are not standardized, whatever the
draft says about static groups will surely conflict with several
implementations.  Vendors may find it infeasible to switch from their
established behavior to what the draft says.

I suggest in any case to keep the behaviour of dynamic and static groups
a bit more separate in the draft, and then say that they do not affect
each other except that duplicates are removed - i.e. excludedMember only
excludes from memberQueryURL, not from static members.  (Assuming I
haven't missed some other interaction.)

I suggested a dgAttribute which could specify that a group should
produce e.g. "roleOccupant" instead of "member".  If you do that, it
would be better to put it in the attribue part of the URL - similar
to what Pierangelo said of an "x-nest" URL extension.

Both draft authors and Pierangelo seem to disagree with me about the
"x-" in URL extensions.  Why do you put it there, if not to suggest that
the extension is private?

-- 
Regards,
Hallvard

---

From: Pierangelo Masarati <[email-masked]>
Date: Wed, 21 Feb 2007 20:48:28 +0100

> filter "(member=candidate DN)" are incorrect membership checks.

Sorry, I'm not following you on this ground - but I must be missing
something obvious.

> the extension is private?

No, I agree with you.  I suggested "x-" extension just to follow the
Authors' naming style.  In fact, we should choose names without any "x-"
or "e-" prefix.

p.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 21 Feb 2007 21:23:37 +0100

> Sorry, I'm not following you on this ground - but I must be missing

The draft says in various places one can use the Search and Compare
operations to check for membership.

However the draft's sections 4.3 and 4.4 (last sentence of each) says
that subclasses (should be subtypes) do not denote members.

Example:

Schema:
  attributetype ( <oid> NAME 'foo' SUP member )
  ...

Entry:
  dn: cn=Some Group
  foo: uid=Someone
  ...

LDAP Compare(base "cn=Some Group", attr "member", val "uid=Someone")
returns compareTrue.  Search filter "(foo=uid=Someone)" matches.

-- 
Regards,
Hallvard