From ldapext-bounces@ietf.org Wed Feb 07 19:23:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx38-0004Jc-PU; Wed, 07 Feb 2007 19:22:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEx37-0004Ib-0y for ldapext@ietf.org; Wed, 07 Feb 2007 19:22:05 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEx32-0007Vs-M9 for ldapext@ietf.org; Wed, 07 Feb 2007 19:22:05 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l180Lg9V006861; Wed, 7 Feb 2007 18:21:42 -0600 Message-ID: <45CA6D24.801@highlandsun.com> Date: Wed, 07 Feb 2007 16:21:56 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Ldapext , Jim Sermersheim Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [ldapext] Dynamic group draft X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 07 20:50:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEyPN-0003hq-2q; Wed, 07 Feb 2007 20:49:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEyPK-0003ft-NU for ldapext@ietf.org; Wed, 07 Feb 2007 20:49:06 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEyPG-0001ik-Db for ldapext@ietf.org; Wed, 07 Feb 2007 20:49:06 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l181mmSw008526; Wed, 7 Feb 2007 19:48:48 -0600 Message-ID: <45CA818E.7090705@highlandsun.com> Date: Wed, 07 Feb 2007 17:49:02 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Ldapext , Jim Sermersheim Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> In-Reply-To: <45CA6D24.801@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Howard Chu wrote: > 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? > 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. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 08 05:37:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF6dy-0000wI-FY; Thu, 08 Feb 2007 05:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF6dw-0000w7-RX for ldapext@ietf.org; Thu, 08 Feb 2007 05:36:44 -0500 Received: from lucius.provo.novell.com ([137.65.248.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF6dp-0001Y6-EG for ldapext@ietf.org; Thu, 08 Feb 2007 05:36:44 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Thu, 08 Feb 2007 03:36:34 -0700 Message-Id: <45CB4B53.F25D.00B6.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Thu, 08 Feb 2007 03:38:22 -0700 From: "Haripriya S" To: "Howard Chu" ,"Ldapext" , "Jim Sermersheim" Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> In-Reply-To: <45CA6D24.801@highlandsun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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/msg1544= 1.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. =20 >>> Howard Chu 02/08/07 5:51 AM >>>=20 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=20 these same points on the OpenLDAP- Devel mailing list recently. I = hadn't=20 seen any prior versions of this draft before, can you point me to a=20 forum where it had been discussed? _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 08 12:24:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFCzh-00045O-CQ; Thu, 08 Feb 2007 12:23:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFCzg-00045I-1R for ldapext@ietf.org; Thu, 08 Feb 2007 12:23:36 -0500 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFCzW-0001v9-Ju for ldapext@ietf.org; Thu, 08 Feb 2007 12:23:35 -0500 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.59]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id ED74C34B7C; Thu, 8 Feb 2007 11:23:25 -0600 (CST) Received: from G3W0067.americas.hpqcorp.net ([16.232.1.13]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 11:23:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Dynamic group draft Date: Thu, 8 Feb 2007 11:23:24 -0600 Message-ID: <22F5E36297524347B40AFAA7CDD4CB4DE1F3EA@G3W0067.americas.hpqcorp.net> In-Reply-To: <45CA818E.7090705@highlandsun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ldapext] Dynamic group draft Thread-Index: AcdLI3wuLjh6gGaRR8qLMz50UzuVxQAfbmyA References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> From: "Neal-Joslin, Robert (HP-UX Lab R&D)" To: "Howard Chu" , "Ldapext" , "Jim Sermersheim" X-OriginalArrivalTime: 08 Feb 2007 17:23:25.0162 (UTC) FILETIME=[D6F81CA0:01C74BA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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:hyc@highlandsun.com]=20 > Sent: Wednesday, February 07, 2007 5:49 PM > To: Ldapext; Jim Sermersheim > Subject: Re: [ldapext] Dynamic group draft >=20 > Howard Chu wrote: > > While I don't think there was ever a formal spec published,=20 > a lot of=20 > > vendors already use the memberURL attribute that Netscape=20 > defined for=20 > > their default dynamic group implementation. Why did you feel it was=20 > > necessary to define a new "memberQueryURL" attribute that is=20 > > essentially identical in meaning to memberURL? > > > Actually looking over our implementation in OpenLDAP, I guess that=20 > defining a new attribute is probably a good move. But it=20 > should inherit=20 > from labeledURI, to make its semantics more obvious. >=20 > --=20 > -- 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/ >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 08 16:46:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFH5E-0005sa-Bi; Thu, 08 Feb 2007 16:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFD9C-0000Qj-SM for ldapext@ietf.org; Thu, 08 Feb 2007 12:33:26 -0500 Received: from public.id2-vpn.continvity.gns.novell.com ([195.33.99.129] helo=gwia-smtp.id2.novell.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFD9B-00042d-GV for ldapext@ietf.org; Thu, 08 Feb 2007 12:33:26 -0500 Received: from [192.168.1.4] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Thu, 08 Feb 2007 17:33:13 +0000 Message-ID: <45CB5EBD.3050304@novell.com> Date: Thu, 08 Feb 2007 23:02:45 +0530 From: Jaimon Jose User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Howard Chu Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> In-Reply-To: <45CA6D24.801@highlandsun.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Thu, 08 Feb 2007 16:45:35 -0500 Cc: Haripriya S , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jjaimon@novell.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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. > 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. Thanks for pointing this out. I will correct them. > 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. 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 08 18:27:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIfJ-0003jJ-9w; Thu, 08 Feb 2007 18:26:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIfB-0003Ko-PI for ldapext@ietf.org; Thu, 08 Feb 2007 18:26:49 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFIUw-0006Y7-21 for ldapext@ietf.org; Thu, 08 Feb 2007 18:16:18 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l18NG4E0000933; Thu, 8 Feb 2007 17:16:05 -0600 Message-ID: <45CBAF38.5010905@highlandsun.com> Date: Thu, 08 Feb 2007 15:16:08 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CB5EBD.3050304@novell.com> In-Reply-To: <45CB5EBD.3050304@novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Haripriya S , "Neal-Joslin, Robert \(HP-UX Lab R&D\)" , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Jaimon Jose wrote: > 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. > > 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]] = ... 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 > 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. > 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. >> 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. >> > Thanks for pointing this out. I will correct them. > >> 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. >> > 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? > 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. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 08 20:33:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKcc-0003TS-Tv; Thu, 08 Feb 2007 20:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFKcb-0003TL-Av for ldapext@ietf.org; Thu, 08 Feb 2007 20:32:17 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFKcV-0001vN-Vd for ldapext@ietf.org; Thu, 08 Feb 2007 20:32:17 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l191W8BS004516 for ; Thu, 8 Feb 2007 19:32:08 -0600 Message-ID: <45CBCF1C.6080104@highlandsun.com> Date: Thu, 08 Feb 2007 17:32:12 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [ldapext] NameAndOptionalUID, uniqueMember, RFC4517, RFC4519 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Probably a little late for this... It seems to me that the description of this syntax and attribute are deficient because they make no direct reference to the x500UniqueIdentifier attribute, which is an inherent component of this type. I.e., the syntax definition offers no description of where the unique identifier came from, it's described as if it is just an arbitrary bitstring that came out of the blue. But in fact it is specifically the content of the x500UniqueIdentifier attribute of the named entry. Likewise, the example for uniqueMember in RFC4519 is deficient. It says "a new battalion with the "same" name would have a unique identifier value added" but this fails to note that the identifier must live somewhere, not just in the uniqueMember attribute itself. That is, it should explicitly say that an x500UniqueIdentifier is added to the target entry, and its value gets used in the uniqueMember attribute value. Overall the example leaves a lot to be desired; an object named by an "ou" attribute is most likely an organizationalUnit, but x500UniqueIdentifier is not a valid attribute of that object class. In fact the only object class in any published RFC that uses x500UniqueIdentifier is inetOrgPerson, in RFC2798. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Feb 09 16:14:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFd2u-0000Ui-WC; Fri, 09 Feb 2007 16:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFd2t-0000Qx-DS for ldapext@ietf.org; Fri, 09 Feb 2007 16:12:39 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFd2r-0008Os-Nv for ldapext@ietf.org; Fri, 09 Feb 2007 16:12:39 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l19LBikT009230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Feb 2007 22:11:48 +0100 Message-ID: <45CCE420.4040600@sys-net.it> Date: Fri, 09 Feb 2007 22:14:08 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Howard Chu Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> In-Reply-To: <45CA6D24.801@highlandsun.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Howard Chu wrote: > 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? One point that puzzles me is a security concern, which was extensively discussed about OpenLDAP's slapo-dynlist(5) overlay 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: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sat Feb 10 05:53:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFppk-0001G5-U4; Sat, 10 Feb 2007 05:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFppj-0001Fy-Rd for ldapext@ietf.org; Sat, 10 Feb 2007 05:51:55 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFppi-0006aq-Dh for ldapext@ietf.org; Sat, 10 Feb 2007 05:51:55 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1AAouto018377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Feb 2007 11:51:00 +0100 Message-ID: <45CDA427.4050108@sys-net.it> Date: Sat, 10 Feb 2007 11:53:27 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Howard Chu Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> In-Reply-To: <45CA6D24.801@highlandsun.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Howard Chu wrote: > 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. 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 From ldapext-bounces@ietf.org Sat Feb 10 06:30:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFqPk-0001Vx-4K; Sat, 10 Feb 2007 06:29:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFqPi-0001Vs-6m for ldapext@ietf.org; Sat, 10 Feb 2007 06:29:06 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFqPf-0006a0-Oh for ldapext@ietf.org; Sat, 10 Feb 2007 06:29:06 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1ABSGZv020313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Feb 2007 12:28:17 +0100 Message-ID: <45CDACE6.3020304@sys-net.it> Date: Sat, 10 Feb 2007 12:30:46 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CDA427.4050108@sys-net.it> In-Reply-To: <45CDA427.4050108@sys-net.it> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Pierangelo Masarati wrote: > Howard Chu wrote: > >> 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. 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 From ldapext-bounces@ietf.org Sat Feb 10 08:03:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFrs8-0006wB-RP; Sat, 10 Feb 2007 08:02:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFrs7-0006vw-OO for ldapext@ietf.org; Sat, 10 Feb 2007 08:02:31 -0500 Received: from lucius.provo.novell.com ([137.65.248.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HFrs2-0007Vg-6r for ldapext@ietf.org; Sat, 10 Feb 2007 08:02:31 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Sat, 10 Feb 2007 06:02:19 -0700 Message-Id: <45CE0F35.F25D.00B6.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Sat, 10 Feb 2007 06:02:43 -0700 From: "Haripriya S" To: "Howard Chu" , "Pierangelo Masarati" Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> In-Reply-To: <45CCE420.4040600@sys-net.it> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Jim Sermersheim , Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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 =20 >>> Pierangelo Masarati 02/10/07 2:44 AM >>>=20 Howard Chu wrote: > http://www.ietf.org/internet- drafts/draft- haripriya- dynamicgroup- = 02.txt >=20 > 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? One point that puzzles me is a security concern, which was extensively discussed about OpenLDAP's slapo- dynlist(5) overlay 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: pierangelo.masarati@sys- net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Feb 11 04:48:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGBIZ-0005Wb-W8; Sun, 11 Feb 2007 04:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGBIY-0005WV-NU for ldapext@ietf.org; Sun, 11 Feb 2007 04:47:06 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGBIX-0005An-88 for ldapext@ietf.org; Sun, 11 Feb 2007 04:47:06 -0500 Received: from ns1.sys-net.it (localhost [127.0.0.1]) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1B9kKD1002074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Feb 2007 10:46:20 +0100 Received: (from apache@localhost) by ns1.sys-net.it (8.13.5.20060308/8.12.5/Submit) id l1B9kKJ5002072; Sun, 11 Feb 2007 10:46:20 +0100 Received: from 151.24.111.96 (SquirrelMail authenticated user ando); by webmail.sys-net.it with HTTP; Sun, 11 Feb 2007 10:46:19 +0100 (CET) Message-ID: <1195.151.24.111.96.1171187179.squirrel@151.24.111.96> In-Reply-To: <45CE0F35.F25D.00B6.0@novell.com> References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> Date: Sun, 11 Feb 2007 10:46:19 +0100 (CET) Subject: Re: [ldapext] Dynamic group draft From: "Pierangelo Masarati" To: "Haripriya S" User-Agent: SquirrelMail/1.4.3a-1 X-Mailer: SquirrelMail/1.4.3a-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Status: No, score=-4.4 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Jim Sermersheim , Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ando@sys-net.it List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org > 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. 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 From ldapext-bounces@ietf.org Sun Feb 11 17:41:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGNMA-0001qt-84; Sun, 11 Feb 2007 17:39:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGNM9-0001qo-76 for ldapext@ietf.org; Sun, 11 Feb 2007 17:39:37 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGNM7-0006Y3-Ml for ldapext@ietf.org; Sun, 11 Feb 2007 17:39:37 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1BMcn9M005080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Feb 2007 23:38:50 +0100 Message-ID: <45CF9B1A.1090509@sys-net.it> Date: Sun, 11 Feb 2007 23:39:22 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Haripriya S Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> In-Reply-To: <45CE0F35.F25D.00B6.0@novell.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Jim Sermersheim , Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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. 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 From ldapext-bounces@ietf.org Sun Feb 11 23:39:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGSxF-0004Q4-7q; Sun, 11 Feb 2007 23:38:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGSxE-0004Pz-Ax for ldapext@ietf.org; Sun, 11 Feb 2007 23:38:16 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGSxD-0006Ka-1F for ldapext@ietf.org; Sun, 11 Feb 2007 23:38:16 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1C4cBDs016034; Sun, 11 Feb 2007 23:38:11 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1C4cB5q019703; Sun, 11 Feb 2007 23:38:11 -0500 Received: from [10.13.248.27] (vpn-248-27.boston.redhat.com [10.13.248.27]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l1C4c8cP028644; Sun, 11 Feb 2007 23:38:09 -0500 Message-ID: <45CFEF2A.7020707@redhat.com> Date: Sun, 11 Feb 2007 20:38:02 -0800 From: Pete Rowley User-Agent: Thunderbird 1.5.0.9 (X11/20061215) MIME-Version: 1.0 To: Howard Chu Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> In-Reply-To: <45CA6D24.801@highlandsun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1889480540==" Errors-To: ldapext-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1889480540== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030903020203020901030308" This is a cryptographically signed message in MIME format. --------------ms030903020203020901030308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > 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 --------------ms030903020203020901030308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEDviSvktA94T6A8TxUShd9AwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTExNTA4MDUyMFoX DTA3MTExNTA4MDUyMFowRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEApRABgFPN60gQLIQRuuKGvf1ZEPfxgVykZrd3uIzpJ8ipQlQMujFQMIT+i6Q/ lBTwxDIncumO3HBJraWx8dUdimys4dG+zOsI0ajjO4TeIRMFkS9/njnsKbNH6j721WY+VuaZ FOYN0xcAOAKyaSrnHIl7N7PFF1VlUwGdd/QlzgBsXnFDIJrejBE0EDM9iXEVvnoDiMQQg81H 5O7ZZGl6ra04MT19hsYkdZFT/ajuD6+Rr5LjqoIE2vYlpBj5gL0z1Mg6NNygtOT91UQN4BVo YD4fx+PFAgcSxLo7TBM9DBftPAkgHsHlWWuVSXl0kbvO1ps/TRo31Y8yO463mrHEpQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOBgQA5oUNvfvaG1tRLI1BM8Pn3eENhvv6b8VR5aG07MXCsqhw5MNXkTzQx UMFCze6IMLecAt+zRYh0i09oeMJXudctJZCPXSRg4ygSDJ0dIVhz7v5ExIyEm5DCfzEBlIbl eP/3B4rADYzdlxa63n5akR2EvDkwi0/a2byeLU/MMk9LFDCCAt4wggJHoAMCAQICEDviSvkt A94T6A8TxUShd9AwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTExNTA4MDUyMFoXDTA3MTExNTA4MDUyMFowRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRABgFPN60gQ LIQRuuKGvf1ZEPfxgVykZrd3uIzpJ8ipQlQMujFQMIT+i6Q/lBTwxDIncumO3HBJraWx8dUd imys4dG+zOsI0ajjO4TeIRMFkS9/njnsKbNH6j721WY+VuaZFOYN0xcAOAKyaSrnHIl7N7PF F1VlUwGdd/QlzgBsXnFDIJrejBE0EDM9iXEVvnoDiMQQg81H5O7ZZGl6ra04MT19hsYkdZFT /ajuD6+Rr5LjqoIE2vYlpBj5gL0z1Mg6NNygtOT91UQN4BVoYD4fx+PFAgcSxLo7TBM9DBft PAkgHsHlWWuVSXl0kbvO1ps/TRo31Y8yO463mrHEpQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA5oUNv fvaG1tRLI1BM8Pn3eENhvv6b8VR5aG07MXCsqhw5MNXkTzQxUMFCze6IMLecAt+zRYh0i09o eMJXudctJZCPXSRg4ygSDJ0dIVhz7v5ExIyEm5DCfzEBlIbleP/3B4rADYzdlxa63n5akR2E vDkwi0/a2byeLU/MMk9LFDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQO+JK+S0D 3hPoDxPFRKF30DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNzAyMTIwNDM4MDJaMCMGCSqGSIb3DQEJBDEWBBRgUVtqMEPyjJbx i6cpGJW8YRYbXzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDvi SvktA94T6A8TxUShd9AwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDviSvktA94T6A8TxUShd9AwDQYJKoZIhvcN AQEBBQAEggEAAo7j6kQTH3JyEuibGiHFtpopUzHrv+eg4jmRANhBXBTR10I91VlK4roRySIS nen327ZO6rrvuTrYzX3Shqnr2SGgJbveCOyk5DL2r54LXire1/dfb67xXsDI4DJ8cdBGtxjr HkpV07Kwkj99xmG4dMG72sKpggQNPbRLUmiYOMRO1lwOJdLBXXpSDo9AIltEbRvPpMgOnqkM gKX2x7EaGZRiocP4UzJqG7bZJpLGsweRyJRy4FGyPTCIaS6GlVPF/0zVoRJWHGbX/kFSYJ4P HrU4gmm3n7ER5EGsm57jndGmOeByb1PIV8PeKvthPMmmnUA7/PwZxkzJE82YAFg3QgAAAAAA AA== --------------ms030903020203020901030308-- --===============1889480540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1889480540==-- From ldapext-bounces@ietf.org Mon Feb 12 02:01:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVAv-0007TO-2k; Mon, 12 Feb 2007 02:00:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGVAt-0007TE-Vh for ldapext@ietf.org; Mon, 12 Feb 2007 02:00:31 -0500 Received: from mail.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGVAq-0002Kd-Kb for ldapext@ietf.org; Mon, 12 Feb 2007 02:00:31 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 4D5A7162AE0; Mon, 12 Feb 2007 07:00:20 +0000 (GMT) Subject: Re: [ldapext] Dynamic group draft From: simo To: Pete Rowley In-Reply-To: <45CFEF2A.7020707@redhat.com> References: <45CA6D24.801@highlandsun.com> <45CFEF2A.7020707@redhat.com> Content-Type: text/plain Organization: Samba Team Date: Mon, 12 Feb 2007 02:00:20 -0500 Message-Id: <1171263620.21336.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: idra@samba.org List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Sun, 2007-02-11 at 20:38 -0800, Pete Rowley wrote: > Howard Chu wrote: > > 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). 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: idra@samba.org http://samba.org _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Feb 12 03:31:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWaC-0003S5-Ha; Mon, 12 Feb 2007 03:30:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGWaB-0003Rr-9Q for ldapext@ietf.org; Mon, 12 Feb 2007 03:30:43 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGWa9-0003tT-NR for ldapext@ietf.org; Mon, 12 Feb 2007 03:30:43 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1C8Tr6Y003256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Feb 2007 09:29:53 +0100 Message-ID: <45D025A1.8080202@sys-net.it> Date: Mon, 12 Feb 2007 09:30:25 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Pete Rowley Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CFEF2A.7020707@redhat.com> In-Reply-To: <45CFEF2A.7020707@redhat.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Pete Rowley wrote: > Howard Chu wrote: >> 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). 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. 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 From ldapext-bounces@ietf.org Mon Feb 12 04:21:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGXMR-00055L-CI; Mon, 12 Feb 2007 04:20:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGXMP-00055G-Tc for ldapext@ietf.org; Mon, 12 Feb 2007 04:20:33 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGXMO-0005m1-Kz for ldapext@ietf.org; Mon, 12 Feb 2007 04:20:33 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1C9KP3e010103; Mon, 12 Feb 2007 04:20:25 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1C9KO3d029579; Mon, 12 Feb 2007 04:20:25 -0500 Received: from [10.13.248.27] (vpn-248-27.boston.redhat.com [10.13.248.27]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l1C9KJuc011290; Mon, 12 Feb 2007 04:20:21 -0500 Message-ID: <45D03151.7050801@redhat.com> Date: Mon, 12 Feb 2007 01:20:17 -0800 From: Pete Rowley User-Agent: Thunderbird 1.5.0.9 (X11/20061215) MIME-Version: 1.0 To: Pierangelo Masarati Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CFEF2A.7020707@redhat.com> <45D025A1.8080202@sys-net.it> In-Reply-To: <45D025A1.8080202@sys-net.it> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1963472559==" Errors-To: ldapext-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1963472559== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060901080801080501080509" This is a cryptographically signed message in MIME format. --------------ms060901080801080501080509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pierangelo Masarati wrote: > > 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, 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, > and the dynamic generation of part of the members should go unnoticed. > > 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. > - 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) > right, which breaks the existing model and existing clients. > - 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) > that's a good thing (TM) > With respect to nested grouping, that's an interesting point. I would > allow it for implementations that can guarantee that loops are > 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 > that clients do not add dynamic group members to a dynamic group under > the assumption they will be expanded. > 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. > 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. > I understand your reservation on that, it isn't pretty. -- Pete --------------ms060901080801080501080509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEDviSvktA94T6A8TxUShd9AwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTExNTA4MDUyMFoX DTA3MTExNTA4MDUyMFowRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEApRABgFPN60gQLIQRuuKGvf1ZEPfxgVykZrd3uIzpJ8ipQlQMujFQMIT+i6Q/ lBTwxDIncumO3HBJraWx8dUdimys4dG+zOsI0ajjO4TeIRMFkS9/njnsKbNH6j721WY+VuaZ FOYN0xcAOAKyaSrnHIl7N7PFF1VlUwGdd/QlzgBsXnFDIJrejBE0EDM9iXEVvnoDiMQQg81H 5O7ZZGl6ra04MT19hsYkdZFT/ajuD6+Rr5LjqoIE2vYlpBj5gL0z1Mg6NNygtOT91UQN4BVo YD4fx+PFAgcSxLo7TBM9DBftPAkgHsHlWWuVSXl0kbvO1ps/TRo31Y8yO463mrHEpQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOBgQA5oUNvfvaG1tRLI1BM8Pn3eENhvv6b8VR5aG07MXCsqhw5MNXkTzQx UMFCze6IMLecAt+zRYh0i09oeMJXudctJZCPXSRg4ygSDJ0dIVhz7v5ExIyEm5DCfzEBlIbl eP/3B4rADYzdlxa63n5akR2EvDkwi0/a2byeLU/MMk9LFDCCAt4wggJHoAMCAQICEDviSvkt A94T6A8TxUShd9AwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTExNTA4MDUyMFoXDTA3MTExNTA4MDUyMFowRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRABgFPN60gQ LIQRuuKGvf1ZEPfxgVykZrd3uIzpJ8ipQlQMujFQMIT+i6Q/lBTwxDIncumO3HBJraWx8dUd imys4dG+zOsI0ajjO4TeIRMFkS9/njnsKbNH6j721WY+VuaZFOYN0xcAOAKyaSrnHIl7N7PF F1VlUwGdd/QlzgBsXnFDIJrejBE0EDM9iXEVvnoDiMQQg81H5O7ZZGl6ra04MT19hsYkdZFT /ajuD6+Rr5LjqoIE2vYlpBj5gL0z1Mg6NNygtOT91UQN4BVoYD4fx+PFAgcSxLo7TBM9DBft PAkgHsHlWWuVSXl0kbvO1ps/TRo31Y8yO463mrHEpQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA5oUNv fvaG1tRLI1BM8Pn3eENhvv6b8VR5aG07MXCsqhw5MNXkTzQxUMFCze6IMLecAt+zRYh0i09o eMJXudctJZCPXSRg4ygSDJ0dIVhz7v5ExIyEm5DCfzEBlIbleP/3B4rADYzdlxa63n5akR2E vDkwi0/a2byeLU/MMk9LFDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQO+JK+S0D 3hPoDxPFRKF30DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNzAyMTIwOTIwMTdaMCMGCSqGSIb3DQEJBDEWBBSSGRRiSE8yOY1H twCyKKS9NQ2V0zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDvi SvktA94T6A8TxUShd9AwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDviSvktA94T6A8TxUShd9AwDQYJKoZIhvcN AQEBBQAEggEAh6i2/GGuL2HUZfejrJTCOnIRSnx+1hhHSNS1bfqsEKG5/v5djOwYAvKZ6oR/ LwItQ+cblKvXIbbQjVXJlGa44QixIWohna1g4DEwqFdGI9cYr7ZFVR36jyc1ew/iYkNkeCS6 fFsbzRaOhEwvtKhc7zHXy/qfz9G+MmKX0JL4UHUD+WX/igDwagUdED7nX3xGyG/Ukirf+WRO thr9Zea3wVtgTKsHiCRrFjmpEwSXbrBhN/LJgob4mFy+k/b9IQivn7avD2hh/tzscFi36fr4 0cJhD68Y8RER06AFnpkneSgJsEdnocFLZq/9GojcakE7qLoYqraqJpWICXQyVEN0rQAAAAAA AA== --------------ms060901080801080501080509-- --===============1963472559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1963472559==-- From ldapext-bounces@ietf.org Mon Feb 12 11:10:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdjX-0000W0-G0; Mon, 12 Feb 2007 11:08:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdjW-0000Vr-It for ldapext@ietf.org; Mon, 12 Feb 2007 11:08:50 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGdjV-0006qY-9L for ldapext@ietf.org; Mon, 12 Feb 2007 11:08:50 -0500 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HGdjS-0001bv-Dq; Mon, 12 Feb 2007 17:08:46 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx2.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HGdjS-0000oB-0M; Mon, 12 Feb 2007 17:08:46 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HGdjR-0001d4-JM; Mon, 12 Feb 2007 17:08:45 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 12 Feb 2007 17:08:45 +0100 To: Howard Chu Subject: Re: [ldapext] Dynamic group draft In-Reply-To: <45CA818E.7090705@highlandsun.com> References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-3.0, required=12.0, autolearn=disabled, AWL=2.000, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 83921CC69E5809E7E027EE62DD6CAC504FB7A24A X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -29 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 122 max/h 4 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Feb 12 11:43:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeG3-0003UJ-MB; Mon, 12 Feb 2007 11:42:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeG2-0003UA-DW for ldapext@ietf.org; Mon, 12 Feb 2007 11:42:26 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGeFx-0006Ul-2O for ldapext@ietf.org; Mon, 12 Feb 2007 11:42:26 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l1CGgDPm008595; Mon, 12 Feb 2007 10:42:14 -0600 Message-ID: <45D098E8.5010703@highlandsun.com> Date: Mon, 12 Feb 2007 08:42:16 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Hallvard B Furuseth Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hallvard B Furuseth wrote: > 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. > Fair enough. That just brings me back to my earlier point that there should be an actual syntax defined for URLs. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 13 01:55:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGrYe-0007j8-G1; Tue, 13 Feb 2007 01:54:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGrYc-0007iv-RO for ldapext@ietf.org; Tue, 13 Feb 2007 01:54:30 -0500 Received: from public.id2-vpn.continvity.gns.novell.com ([195.33.99.129] helo=gwia-smtp.id2.novell.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGrYb-0000hh-Iv for ldapext@ietf.org; Tue, 13 Feb 2007 01:54:30 -0500 Received: from [164.99.145.130] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 13 Feb 2007 06:54:16 +0000 Message-ID: <45D16079.5030706@novell.com> Date: Tue, 13 Feb 2007 12:23:45 +0530 From: Jaimon Jose User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Hallvard B Furuseth Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Haripriya S , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jjaimon@novell.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hallvard B Furuseth wrote: > And they do not have the same syntax anyway. memberQueryURL does not > 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 13 01:58:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGrbQ-0001T3-Ot; Tue, 13 Feb 2007 01:57:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGrbQ-0001SV-0g for ldapext@ietf.org; Tue, 13 Feb 2007 01:57:24 -0500 Received: from public.id2-vpn.continvity.gns.novell.com ([195.33.99.129] helo=gwia-smtp.id2.novell.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGrbO-0001Tf-Ll for ldapext@ietf.org; Tue, 13 Feb 2007 01:57:24 -0500 Received: from [164.99.145.130] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 13 Feb 2007 06:56:54 +0000 Message-ID: <45D16117.3010207@novell.com> Date: Tue, 13 Feb 2007 12:26:23 +0530 From: Jaimon Jose User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Howard Chu Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> <45D098E8.5010703@highlandsun.com> In-Reply-To: <45D098E8.5010703@highlandsun.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Hallvard B Furuseth , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jjaimon@novell.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Howard Chu wrote: > Fair enough. That just brings me back to my earlier point that there > 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 13 02:17:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGruJ-0002Cr-KY; Tue, 13 Feb 2007 02:16:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGruI-0002Ca-Kk for ldapext@ietf.org; Tue, 13 Feb 2007 02:16:54 -0500 Received: from public.id2-vpn.continvity.gns.novell.com ([195.33.99.129] helo=gwia-smtp.id2.novell.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGruH-0008No-9G for ldapext@ietf.org; Tue, 13 Feb 2007 02:16:54 -0500 Received: from [164.99.145.130] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 13 Feb 2007 07:16:45 +0000 Message-ID: <45D165BD.1010805@novell.com> Date: Tue, 13 Feb 2007 12:46:13 +0530 From: Jaimon Jose User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Pierangelo Masarati Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CDA427.4050108@sys-net.it> In-Reply-To: <45CDA427.4050108@sys-net.it> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jjaimon@novell.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Pierangelo Masarati wrote: > 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". > 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 > an option? > 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. > AUXILIARY classes dynamicGroupAux and dynamicGroupOfUniqueNamesAux > cannot respectively inherit from groupOfNames and groupOfUniqueNames > 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 13 02:39:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGsFJ-00061U-8P; Tue, 13 Feb 2007 02:38:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGsFI-00061O-2g for ldapext@ietf.org; Tue, 13 Feb 2007 02:38:36 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGsFF-0007z8-LC for ldapext@ietf.org; Tue, 13 Feb 2007 02:38:36 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l1D7cOUe027787; Tue, 13 Feb 2007 01:38:25 -0600 Message-ID: <45D16AF5.9020906@highlandsun.com> Date: Mon, 12 Feb 2007 23:38:29 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CDA427.4050108@sys-net.it> <45D165BD.1010805@novell.com> In-Reply-To: <45D165BD.1010805@novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Jaimon Jose wrote: > Pierangelo Masarati wrote: > >> AUXILIARY classes dynamicGroupAux and dynamicGroupOfUniqueNamesAux >> cannot respectively inherit from groupOfNames and groupOfUniqueNames >> 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. 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 > 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. 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. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 13 03:15:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGso6-0007Yz-LR; Tue, 13 Feb 2007 03:14:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGso5-0007X6-M8 for ldapext@ietf.org; Tue, 13 Feb 2007 03:14:33 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGso4-0006wm-6k for ldapext@ietf.org; Tue, 13 Feb 2007 03:14:33 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1D8DhqC010313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Feb 2007 09:13:48 +0100 Message-ID: <45D1735D.9030603@sys-net.it> Date: Tue, 13 Feb 2007 09:14:21 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CDA427.4050108@sys-net.it> <45D165BD.1010805@novell.com> In-Reply-To: <45D165BD.1010805@novell.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Jaimon Jose wrote: > Pierangelo Masarati wrote: >> 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". >> > > 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? 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. >> BTW, would prefixing "memberQueryURL" and "excludedMember" with "dg" be >> an option? >> > 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. >> AUXILIARY classes dynamicGroupAux and dynamicGroupOfUniqueNamesAux >> cannot respectively inherit from groupOfNames and groupOfUniqueNames >> 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. 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. 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 From ldapext-bounces@ietf.org Tue Feb 13 19:04:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7cH-0007Pl-Dx; Tue, 13 Feb 2007 19:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH7cG-0007PY-Pn for ldapext@ietf.org; Tue, 13 Feb 2007 19:03:20 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH7cB-0007nA-77 for ldapext@ietf.org; Tue, 13 Feb 2007 19:03:20 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l1E034un030637 for ; Tue, 13 Feb 2007 18:03:05 -0600 Message-ID: <45D251C0.2050306@highlandsun.com> Date: Tue, 13 Feb 2007 16:03:12 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070213 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [ldapext] [Fwd: LDAP C API gripes] X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org I've created this page http://scratchpad.wikia.com/wiki/LDAP_C_API for putting together ideas for a new LDAP C API. The fact that the last LDAPv3 API doc never made it out of draft status really needs to be addressed, and there are so many flaws with the API (essentially inherited from the LDAPv2 API) that it's obvious a simple refresh is inadequate. The fact that groups like the Samba team have decided it was necessary to create their own LDAP API underscores the point. If anybody has comments on what is broken and how it can be fixed, please chime in. -------- Original Message -------- Subject: LDAP C API gripes Date: Mon, 12 Feb 2007 06:27:41 -0800 Probably this should just go out on the ldapext mailing list again. The main discussion I referred to started here http://www.openldap.org/lists/openldap-devel/200312/msg00123.html I posted my laundry list here http://www.openldap.org/lists/openldap-devel/200312/msg00187.html Kurt's followup adds some other considerations. The list thus far: 1) Needs an explicit library_init/library_destroy and a library_handle. (No static/global state, everything referenced by the library_handle.) 2) APIs for operations must have a function parameter for every operation protocol parameter. (E.g., current ldap_search variations all omit DEREF, so you can only specify this via ldap_set_option. Ugly.) 2a) Functions with long parameter lists are difficult to manage. Perhaps use request structures/parameter blocks, like 2.2 slapd. 2b) Simplified APIs are still desirable, for apps that don't care about controls/extensions/whatever. 3) Requests and results must be bound together. (E.g., ldap_get_option( OPT_ERROR_NUMBER) has no notion of which result's error is being retrieved.) 4) char *'s should be avoided, use struct bervals more extensively 4a) the API is too malloc-happy. result parsing etc. should be done in-place as much as possible. - "proper" error handling Any routine which can "fail" (e.g., most) should return a clear indication of success or the nature of the failure. ("fail" here refers to API failure, not a protocol failure.) Protocol errors are not to be treated as API errors. no ld_errno, no ld->ld_errno, etc.. (This relates to Howard's #3.) - API designed for thread-free implementation - Ability to provide filters in native (LBER) form - Applications provided extensibility where ever the ASN.1 allows it - Applications allowed to "register" new error codes, etc.. - ldap_* be a low-level LDAP API (one-to-one mapping of API to protocol). Higher level "directory" API provided above to handle referral chasing and such. Another gripe I noted was that a lot of APIs are poorly named, but that should be an easy one to fix along the way. Obviously from the Samba side we need APIs that allow an external event handler to interact with the API. This includes using an already connected socket with the library, and being able to trigger response processing based on an external trigger/callback/whatever. If you have suggestions for who else to get involved, let me know, and just forward this on. Once we figure out the correct forum for the discussion we can go on from there. Perhaps we should use the FAQ-o-Matic or a wiki for maintaining the updated list and evolving the spec. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Feb 15 07:21:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfbD-0004gE-Ew; Thu, 15 Feb 2007 07:20:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfbC-0004eA-1K for ldapext@ietf.org; Thu, 15 Feb 2007 07:20:30 -0500 Received: from lucius.provo.novell.com ([137.65.248.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHfbA-00055i-L3 for ldapext@ietf.org; Thu, 15 Feb 2007 07:20:30 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Thu, 15 Feb 2007 05:20:23 -0700 Message-Id: <45D49D4D.A648.00B6.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Thu, 15 Feb 2007 05:23:07 -0700 From: "Haripriya S" To: "Pierangelo Masarati" Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45CF9B1A.1090509@sys-net.it> In-Reply-To: <45CF9B1A.1090509@sys-net.it> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Jim Sermersheim , Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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 02/12/07 4:09 AM >>>=20 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. >=20 > 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. 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 From ldapext-bounces@ietf.org Sat Feb 17 10:14:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIRFl-0002CH-RR; Sat, 17 Feb 2007 10:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIRFl-0002C9-7c for ldapext@ietf.org; Sat, 17 Feb 2007 10:13:33 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIRFj-0007Iv-Mf for ldapext@ietf.org; Sat, 17 Feb 2007 10:13:33 -0500 Received: from [192.168.1.199] (dossi.sys-net.it [87.28.220.33]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1HFCiwY014672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Feb 2007 16:12:45 +0100 Message-ID: <45D71B9E.1000605@sys-net.it> Date: Sat, 17 Feb 2007 16:13:34 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Haripriya S Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45CF9B1A.1090509@sys-net.it> <45D49D4D.A648.00B6.0@novell.com> In-Reply-To: <45D49D4D.A648.00B6.0@novell.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Jim Sermersheim , Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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//memberQueryURL="" read where 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 From ldapext-bounces@ietf.org Tue Feb 20 07:22:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTzd-0004dK-OT; Tue, 20 Feb 2007 07:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTzd-0004dF-9V for ldapext@ietf.org; Tue, 20 Feb 2007 07:21:13 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJTzc-0008LU-0M for ldapext@ietf.org; Tue, 20 Feb 2007 07:21:13 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJTzX-0006M9-Fc; Tue, 20 Feb 2007 13:21:07 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx3.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJTzV-0002j6-1L; Tue, 20 Feb 2007 13:21:07 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJTzU-0002b5-ME; Tue, 20 Feb 2007 13:21:04 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 20 Feb 2007 13:21:04 +0100 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft In-Reply-To: <45D16079.5030706@novell.com> References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> <45D16079.5030706@novell.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.4, required=12.0, autolearn=disabled, AWL=0.625, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 8372AD9786F4CBD9F15F2978B89B06158EF9C0F2 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -43 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 154 max/h 4 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Haripriya S , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Jaimon Jose writes: >Hallvard B Furuseth wrote: >> (...) memberQueryURL does not >> allow a general URI, nor the label part of labeledURI. > > (...) 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 20 10:55:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXKI-0000QI-5T; Tue, 20 Feb 2007 10:54:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXKG-0000KJ-CT for ldapext@ietf.org; Tue, 20 Feb 2007 10:54:44 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXKE-00024W-Ln for ldapext@ietf.org; Tue, 20 Feb 2007 10:54:44 -0500 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJXKE-00016D-2m; Tue, 20 Feb 2007 16:54:42 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx4.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJXKD-0006xH-GS; Tue, 20 Feb 2007 16:54:42 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJXKD-0003w9-E9; Tue, 20 Feb 2007 16:54:41 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 20 Feb 2007 16:54:41 +0100 To: Haripriya S Subject: Re: [ldapext] Dynamic group draft In-Reply-To: <45CE0F35.F25D.00B6.0@novell.com> References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.3, required=12.0, autolearn=disabled, AWL=0.724, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 73ADC5DDB2AD9E877AFCEA31DAB2D338DB21C873 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -42 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 156 max/h 4 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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=) - "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 From ldapext-bounces@ietf.org Tue Feb 20 14:13:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaPB-0005H8-Nq; Tue, 20 Feb 2007 14:12:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaPA-0005H3-6e for ldapext@ietf.org; Tue, 20 Feb 2007 14:12:00 -0500 Received: from public.id2-vpn.continvity.gns.novell.com ([195.33.99.129] helo=gwia-smtp.id2.novell.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJaP9-0006cU-FI for ldapext@ietf.org; Tue, 20 Feb 2007 14:12:00 -0500 Received: from [192.168.1.2] (l4-client.id2.novell.com [::ffff:149.44.117.251]) by gwia-smtp.id2.novell.com with ESMTP (TLS encrypted); Tue, 20 Feb 2007 19:11:29 +0000 Message-ID: <45DB47D8.8060305@novell.com> Date: Wed, 21 Feb 2007 00:41:20 +0530 From: Jaimon Jose User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Hallvard B Furuseth Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: Haripriya S , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jjaimon@novell.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Thanks for the detailed comment. Please find my responses inline... Hallvard B Furuseth wrote: > 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. > "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. > 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. > 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. 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. > 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. > 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. > Right. Again, this was left to the implementation to decide how to authenticate to the remote server while chaining. > 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. > 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. 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. > 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. > > 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. > 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. > 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. > Possible. Again the reason I mentioned above holds good. > > As far as I can tell, a search for (member=) - "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. > 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.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. > I'll make the change. > 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. > 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. > You are right. This will be updated. > 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. > 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. > I need to read more about this. > 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_. > :-). 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Feb 20 15:35:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbga-0004N5-8J; Tue, 20 Feb 2007 15:34:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbgZ-0004N0-I3 for ldapext@ietf.org; Tue, 20 Feb 2007 15:34:03 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbgV-00067Y-QY for ldapext@ietf.org; Tue, 20 Feb 2007 15:34:02 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1KKXARV026052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Feb 2007 21:33:16 +0100 Message-ID: <45DB5B2E.3020702@sys-net.it> Date: Tue, 20 Feb 2007 21:33:50 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45DB47D8.8060305@novell.com> In-Reply-To: <45DB47D8.8060305@novell.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Haripriya S , Hallvard B Furuseth , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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=) - "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 From ldapext-bounces@ietf.org Tue Feb 20 15:47:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbt9-0002SI-O9; Tue, 20 Feb 2007 15:47:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbt8-0002SC-Qw for ldapext@ietf.org; Tue, 20 Feb 2007 15:47:02 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbt8-0008Dn-13 for ldapext@ietf.org; Tue, 20 Feb 2007 15:47:02 -0500 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJbt7-0003Of-0z; Tue, 20 Feb 2007 21:47:01 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx8.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJbt6-0002HG-9U; Tue, 20 Feb 2007 21:47:00 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJbt6-0005mr-6z; Tue, 20 Feb 2007 21:47:00 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 20 Feb 2007 21:47:00 +0100 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft In-Reply-To: <45DB47D8.8060305@novell.com> References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45DB47D8.8060305@novell.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.1, required=12.0, autolearn=disabled, AWL=0.888, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: A29A870DEF494EB69E4A9EB86C77568F8923CFB5 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -40 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 157 max/h 4 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: Haripriya S , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org 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=) - "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 From ldapext-bounces@ietf.org Wed Feb 21 10:48:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJth3-00046a-IO; Wed, 21 Feb 2007 10:47:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJth1-00044l-H7 for ldapext@ietf.org; Wed, 21 Feb 2007 10:47:43 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtgw-000409-AO for ldapext@ietf.org; Wed, 21 Feb 2007 10:47:42 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l1LFlUM6003715 for ; Wed, 21 Feb 2007 09:47:30 -0600 Message-ID: <45DC6997.5020906@highlandsun.com> Date: Wed, 21 Feb 2007 07:47:35 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070213 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Ldapext Subject: Re: [ldapext] [Fwd: LDAP C API gripes] References: <45D251C0.2050306@highlandsun.com> In-Reply-To: <45D251C0.2050306@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Howard Chu wrote: > I've created this page http://scratchpad.wikia.com/wiki/LDAP_C_API > for putting together ideas for a new LDAP C API. The fact that the > last LDAPv3 API doc never made it out of draft status really needs to > be addressed, and there are so many flaws with the API (essentially > inherited from the LDAPv2 API) that it's obvious a simple refresh is > inadequate. The fact that groups like the Samba team have decided it > was necessary to create their own LDAP API underscores the point. If > anybody has comments on what is broken and how it can be fixed, please > chime in. Something else that comes to mind - the client library ought to be schema-aware. This is something that was always a given in X.500 clients, but has never had any priority in LDAP clients. It might be worthwhile to implement syntax validation in the library, to catch bogus inputs before talking to any servers... -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 11:12:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJu4A-00038f-UY; Wed, 21 Feb 2007 11:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJu49-00038C-6X for ldapext@ietf.org; Wed, 21 Feb 2007 11:11:37 -0500 Received: from mail.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJu3p-0002de-Qi for ldapext@ietf.org; Wed, 21 Feb 2007 11:11:37 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 9B837163832; Wed, 21 Feb 2007 16:11:17 +0000 (GMT) Subject: Re: [ldapext] [Fwd: LDAP C API gripes] From: simo To: Howard Chu In-Reply-To: <45DC6CCF.6060100@highlandsun.com> References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> <1172073139.11482.11.camel@localhost.localdomain> <45DC6CCF.6060100@highlandsun.com> Content-Type: text/plain Organization: Samba Team Date: Wed, 21 Feb 2007 11:11:17 -0500 Message-Id: <1172074277.11482.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: idra@samba.org List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Wed, 2007-02-21 at 08:01 -0800, Howard Chu wrote: > simo wrote: > > On Wed, 2007-02-21 at 07:47 -0800, Howard Chu wrote: > > > >> Something else that comes to mind - the client library ought to be > >> schema-aware. This is something that was always a given in X.500 > >> clients, but has never had any priority in LDAP clients. It might be > >> worthwhile to implement syntax validation in the library, to catch bogus > >> inputs before talking to any servers... > >> > > > > Does it mean making the client retrieve the schema from the server each > > time? Might work on long lived apps, but an ldapadd would terribly > > suffer ... > > > > This would only be part of a higher level API. I would only expect GUI > tools to use it, although if you're ldapadding a 512MB LDIF it might be > worthwhile to use it on the commandline too. Still the idea does not really appeal me, can you summarize very quickly what advantage do you get in doing that? Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: idra@samba.org http://samba.org _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 11:25:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJuGy-0007GR-G4; Wed, 21 Feb 2007 11:24:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJuGw-0007Fs-QQ for ldapext@ietf.org; Wed, 21 Feb 2007 11:24:50 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJuGu-0006WM-CF for ldapext@ietf.org; Wed, 21 Feb 2007 11:24:50 -0500 Received: from [192.168.1.104] ((unknown) [24.176.246.106]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Feb 2007 16:24:47 +0000 X-SMTP-Protocol-Errors: NORDNS In-Reply-To: <45DC6997.5020906@highlandsun.com> References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Subject: Re: [ldapext] [Fwd: LDAP C API gripes] Date: Wed, 21 Feb 2007 08:24:42 -0800 To: Howard Chu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Feb 21, 2007, at 7:47 AM, Howard Chu wrote: > Something else that comes to mind - the client library ought to be > schema-aware. This is something that was always a given in X.500 > clients, but has never had any priority in LDAP clients. It might > be worthwhile to implement syntax validation in the library, to > catch bogus inputs before talking to any servers... Yes. A server is only going to return the most basic information about the problem, if lucky, identify the particular value which is invalid. A syntax validation library could identify what in that value was bad. For instance, consider validation of a value of the uniqueMember attribute. A server might say value x is bad. The library might be able to say that the 1st AVA of the 2nd RDN of the DN component is invalid. Of course, this validation API should be optional. In supporting handheld devices, offloading validation to the server would be a good thing. Of course, a handheld device is probably better offloading all of LDAP to a device service of some sort. -- Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 11:55:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJujp-0005cw-IR; Wed, 21 Feb 2007 11:54:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJujo-0005cn-3s for ldapext@ietf.org; Wed, 21 Feb 2007 11:54:40 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJujj-0004i1-NZ for ldapext@ietf.org; Wed, 21 Feb 2007 11:54:40 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l1LGsTMX005048; Wed, 21 Feb 2007 10:54:30 -0600 Message-ID: <45DC794A.6070208@highlandsun.com> Date: Wed, 21 Feb 2007 08:54:34 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070213 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: david_list@boreham.org Subject: Re: [ldapext] RFC 4533 implementations? References: <45ABBFDE.6000705@sys-net.it> <45ABC8C7.6000709@boreham.org> In-Reply-To: <45ABC8C7.6000709@boreham.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF ldapext WG X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org David Boreham wrote: > Does anyone know if it is possible to proxy Active Directory's > sync protocol (dirsync) to RFC4533 ? > > If it is then it would be interesting/useful to build such a proxy > because it would make AD compatible with RFC4533 clients. > > I know quite a bit about dirsync, having implemented two different > sync products that use it, but I know next to nothing about 4533 > at this point so excuse me if I'm floating off in space... a quick > read of the rfc draft tells me that they're at least superficially > semantically similar. > > I do see a fair but of un-met interest in an open source > general purpose LDAP sync tool. Wider support for 4533 > I think would help. > This is on my todo list. I'm not entirely convinced yet that it will work easily; the fact that Microsoft uses DSA-specific update counters is pretty annoying. I.e., you cannot infer any ordering relationship between update counters from separate servers. If you have ideas on how to approach this, I'm all ears. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 12:03:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJurC-0007Ix-RS; Wed, 21 Feb 2007 12:02:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtv2-00050V-UT for ldapext@ietf.org; Wed, 21 Feb 2007 11:02:13 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJtuC-0001HW-U8 for ldapext@ietf.org; Wed, 21 Feb 2007 11:02:03 -0500 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id l1LG1E6v004040; Wed, 21 Feb 2007 10:01:15 -0600 Message-ID: <45DC6CCF.6060100@highlandsun.com> Date: Wed, 21 Feb 2007 08:01:19 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070213 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: idra@samba.org Subject: Re: [ldapext] [Fwd: LDAP C API gripes] References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> <1172073139.11482.11.camel@localhost.localdomain> In-Reply-To: <1172073139.11482.11.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org simo wrote: > On Wed, 2007-02-21 at 07:47 -0800, Howard Chu wrote: > >> Something else that comes to mind - the client library ought to be >> schema-aware. This is something that was always a given in X.500 >> clients, but has never had any priority in LDAP clients. It might be >> worthwhile to implement syntax validation in the library, to catch bogus >> inputs before talking to any servers... >> > > Does it mean making the client retrieve the schema from the server each > time? Might work on long lived apps, but an ldapadd would terribly > suffer ... > This would only be part of a higher level API. I would only expect GUI tools to use it, although if you're ldapadding a 512MB LDIF it might be worthwhile to use it on the commandline too. -- -- 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 Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 12:21:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJv8e-0001Yi-JA; Wed, 21 Feb 2007 12:20:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtmE-0002of-QH for ldapext@ietf.org; Wed, 21 Feb 2007 10:53:07 -0500 Received: from mail.samba.org ([66.70.73.150] helo=lists.samba.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJtle-00081M-EX for ldapext@ietf.org; Wed, 21 Feb 2007 10:53:06 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id EBD091639B3; Wed, 21 Feb 2007 15:52:19 +0000 (GMT) Subject: Re: [ldapext] [Fwd: LDAP C API gripes] From: simo To: Howard Chu In-Reply-To: <45DC6997.5020906@highlandsun.com> References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> Content-Type: text/plain Organization: Samba Team Date: Wed, 21 Feb 2007 15:52:19 +0000 Message-Id: <1172073139.11482.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: idra@samba.org List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Wed, 2007-02-21 at 07:47 -0800, Howard Chu wrote: > Howard Chu wrote: > > I've created this page http://scratchpad.wikia.com/wiki/LDAP_C_API > > for putting together ideas for a new LDAP C API. The fact that the > > last LDAPv3 API doc never made it out of draft status really needs to > > be addressed, and there are so many flaws with the API (essentially > > inherited from the LDAPv2 API) that it's obvious a simple refresh is > > inadequate. The fact that groups like the Samba team have decided it > > was necessary to create their own LDAP API underscores the point. If > > anybody has comments on what is broken and how it can be fixed, please > > chime in. > > Something else that comes to mind - the client library ought to be > schema-aware. This is something that was always a given in X.500 > clients, but has never had any priority in LDAP clients. It might be > worthwhile to implement syntax validation in the library, to catch bogus > inputs before talking to any servers... Does it mean making the client retrieve the schema from the server each time? Might work on long lived apps, but an ldapadd would terribly suffer ... Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: idra@samba.org http://samba.org _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 12:53:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvdw-0004z5-TZ; Wed, 21 Feb 2007 12:52:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvdw-0004yv-4M for ldapext@ietf.org; Wed, 21 Feb 2007 12:52:40 -0500 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvds-0004bU-Ly for ldapext@ietf.org; Wed, 21 Feb 2007 12:52:40 -0500 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 6D56042BA1; Wed, 21 Feb 2007 12:52:52 -0500 (EST) Date: Wed, 21 Feb 2007 12:52:26 -0500 From: Michael B Allen To: idra@samba.org Subject: Re: [ldapext] [Fwd: LDAP C API gripes] Message-Id: <20070221125226.3e54fb9e.mba2000@ioplex.com> In-Reply-To: <1172074277.11482.17.camel@localhost.localdomain> References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> <1172073139.11482.11.camel@localhost.localdomain> <45DC6CCF.6060100@highlandsun.com> <1172074277.11482.17.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Wed, 21 Feb 2007 11:11:17 -0500 simo wrote: > On Wed, 2007-02-21 at 08:01 -0800, Howard Chu wrote: > > simo wrote: > > > On Wed, 2007-02-21 at 07:47 -0800, Howard Chu wrote: > > > > > >> Something else that comes to mind - the client library ought to be > > >> schema-aware. This is something that was always a given in X.500 > > >> clients, but has never had any priority in LDAP clients. It might be > > >> worthwhile to implement syntax validation in the library, to catch bogus > > >> inputs before talking to any servers... > > >> > > > > > > Does it mean making the client retrieve the schema from the server each > > > time? Might work on long lived apps, but an ldapadd would terribly > > > suffer ... > > > > > > > This would only be part of a higher level API. I would only expect GUI > > tools to use it, although if you're ldapadding a 512MB LDIF it might be > > worthwhile to use it on the commandline too. > > Still the idea does not really appeal me, can you summarize very quickly > what advantage do you get in doing that? We just did an LDAP abstraction API that has "schema awareness". We're doing a PHP extension and we wanted to make things "as simple as possible but not simpler" for the sake of developers. One of the main issues was converting strings from UTF-8 to the locale encoding. If you don't know what attributes are strings you cannot convert them automatically. You would have to some kind of 'get_string' accessor function or just require the developer to either run their web server in the UTF-8 locale or convert strings manually somehow. We wanted to simply return a PHP array with all of the elements properly typed. Not just strings but integers as integers and large integers as double and boolean as 1 or 0, etc. Another issue, as Howard mentions, are GUI tools that work with arbitrary attributes. The classic example is trying to determine which values are binary so that you don't print garbage at the user. IIRC ldapsearch does this by looking at the value and trying to determine if it contains only ascii characters. If it does not, then it base64 encodes it first. As for retrieving the schema from the server at runtime, we did not do that. Not just for performance reasons but more so because there is no standard way to retrieve that information, it is awkward to do so or you cannot do it at all (e.g. RootDSE attributes in AD have no schema definitions). Instead, we attack the problem at three levels: 1) By default all attribute definitions are multivalued binary. This provides full comapibility with the current API. 2) Very common attributes are hardcoded into the library. Types are string, boolean, binary, time, int32, and int64 with flags for single-valued, case-exact and dn. We have a script that can query AD and produce C declarations for all attributes on a set of DNs. Currently we hard code about 150 attributes. 3) We allow the user to set attribute definitions at runtime using a 'plexcel_set_attrdef' function. These defs are associated with the current context object and are released with it. We think this strategy is quite reasonable in terms of performance and complexity. It is backwards compatible by default. Someone has to have "attribute intelligence". It can either be the developer or the API. In the later case the developer can put that "attribute intellegence" into a list of set_attrdef calls somewhere and not have to think about it all the time. Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 13:01:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvlp-0006IB-LG; Wed, 21 Feb 2007 13:00:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvln-0006Hs-GE for ldapext@ietf.org; Wed, 21 Feb 2007 13:00:47 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvlm-0006cw-4f for ldapext@ietf.org; Wed, 21 Feb 2007 13:00:47 -0500 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJvlk-0008LN-8J; Wed, 21 Feb 2007 19:00:44 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx4.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJvlj-0004Su-Vh; Wed, 21 Feb 2007 19:00:44 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJvlj-0005u0-Px; Wed, 21 Feb 2007 19:00:43 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 21 Feb 2007 19:00:43 +0100 To: Kurt Zeilenga Subject: Re: [ldapext] [Fwd: LDAP C API gripes] In-Reply-To: References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.3, required=12.0, autolearn=disabled, AWL=0.679, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 35A2286757216AC1D32469CAE5499D5EA722A2CC X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -42 maxlevel 200 minaction 0 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Kurt Zeilenga writes: > For instance, consider validation of a value of the uniqueMember > attribute. A server might say value x is bad. The library might > be able to say that the 1st AVA of the 2nd RDN of the DN component > is invalid. No reason a server couldn't say that too, in the diagnosticMessage field. OTOH a library can also provide detailed error info which a program can parse. -- Regards, Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 13:09:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvtL-0007Lw-LV; Wed, 21 Feb 2007 13:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvtK-0007LV-HO for ldapext@ietf.org; Wed, 21 Feb 2007 13:08:34 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvtJ-00007o-3r for ldapext@ietf.org; Wed, 21 Feb 2007 13:08:34 -0500 Received: from [192.168.1.104] ((unknown) [24.176.246.106]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Feb 2007 18:08:31 +0000 X-SMTP-Protocol-Errors: NORDNS In-Reply-To: References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44F5C744-B0CD-4DDD-A437-5CDAD4749B8B@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Subject: Re: [ldapext] [Fwd: LDAP C API gripes] Date: Wed, 21 Feb 2007 10:08:26 -0800 To: Hallvard B Furuseth X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Feb 21, 2007, at 10:00 AM, Hallvard B Furuseth wrote: > Kurt Zeilenga writes: >> For instance, consider validation of a value of the uniqueMember >> attribute. A server might say value x is bad. The library might >> be able to say that the 1st AVA of the 2nd RDN of the DN component >> is invalid. > > No reason a server couldn't say that too, in the diagnosticMessage > field. OTOH a library can also provide detailed error info which > a program can parse. Another good reason to provide client side validation is to facilitate conformance with the LDAP specification... RFC 4511, Section 4.1.5 does say: Clients MUST only send attribute values in a request that are valid according to the syntax defined for the attributes. Of course, it's just wishful thinking that clients will actually adhere to this MUST, which is why there are server side validation requirements as well. -- Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 13:09:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvto-0007c9-C6; Wed, 21 Feb 2007 13:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvtn-0007c4-CQ for ldapext@ietf.org; Wed, 21 Feb 2007 13:09:03 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvtl-0000Fl-UY for ldapext@ietf.org; Wed, 21 Feb 2007 13:09:03 -0500 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJvtl-0001Cl-Ef; Wed, 21 Feb 2007 19:09:01 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx6.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJvtl-0002p4-47; Wed, 21 Feb 2007 19:09:01 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJvtl-0005ur-1O; Wed, 21 Feb 2007 19:09:01 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 21 Feb 2007 19:09:01 +0100 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft In-Reply-To: References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45DB47D8.8060305@novell.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.5, required=12.0, autolearn=disabled, AWL=0.469, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 885B500859422CE6D954CE81C9382CEDCEDA3463 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -44 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 2 max/h 2 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Haripriya S , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org I wrote: >>> The x-chain URL extension looks more generally useful than for just >>> groups. I suggest you split it out to a separate draft. > (...) > 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). 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 13:50:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwWo-0003Ev-Rd; Wed, 21 Feb 2007 13:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwWn-0003Eg-7I for ldapext@ietf.org; Wed, 21 Feb 2007 13:49:21 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwWl-00028p-PD for ldapext@ietf.org; Wed, 21 Feb 2007 13:49:21 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1LImBaX023785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Feb 2007 19:48:12 +0100 Message-ID: <45DC9414.7010706@sys-net.it> Date: Wed, 21 Feb 2007 19:48:52 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Michael B Allen Subject: Re: [ldapext] [Fwd: LDAP C API gripes] References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> <1172073139.11482.11.camel@localhost.localdomain> <45DC6CCF.6060100@highlandsun.com> <1172074277.11482.17.camel@localhost.localdomain> <20070221125226.3e54fb9e.mba2000@ioplex.com> In-Reply-To: <20070221125226.3e54fb9e.mba2000@ioplex.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Michael B Allen wrote: > As for retrieving the schema from the server at runtime, we did not do > that. Not just for performance reasons but more so because there is no > standard way to retrieve that information, it is awkward to do so or > you cannot do it at all (e.g. RootDSE attributes in AD have no schema > definitions). There __is__ a standard way, it's described in RFC4512 secton 4.4; the fact that some implementors don't comply with it, or do not populate values as indicated in the standard is a totally different business. 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 From ldapext-bounces@ietf.org Wed Feb 21 13:50:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwX0-0003HA-Au; Wed, 21 Feb 2007 13:49:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwWz-0003H3-3J for ldapext@ietf.org; Wed, 21 Feb 2007 13:49:33 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwWx-0002B8-Pe for ldapext@ietf.org; Wed, 21 Feb 2007 13:49:33 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJwWv-0001FX-Vk; Wed, 21 Feb 2007 19:49:30 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx3.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJwWv-0006mr-GT; Wed, 21 Feb 2007 19:49:29 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJwWv-0006Bf-CV; Wed, 21 Feb 2007 19:49:29 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 21 Feb 2007 19:49:29 +0100 To: jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft In-Reply-To: <45D16117.3010207@novell.com> References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> <45D098E8.5010703@highlandsun.com> <45D16117.3010207@novell.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.4, required=12.0, autolearn=disabled, AWL=0.556, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 4D2A466328D32CB711085F74EA1AA57E81679C74 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -43 maxlevel 200 minaction 2 bait 0 mail/h: 3 total 3 max/h 3 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Jaimon Jose writes: >Howard Chu wrote: >> Fair enough. That just brings me back to my earlier point that there >> 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. 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 14:07:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwnB-0008KJ-Az; Wed, 21 Feb 2007 14:06:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwn9-0008H1-7n for ldapext@ietf.org; Wed, 21 Feb 2007 14:06:15 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwn7-0005xq-Np for ldapext@ietf.org; Wed, 21 Feb 2007 14:06:15 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1LJ5Pk5024763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Feb 2007 20:05:25 +0100 Message-ID: <45DC981B.3050703@sys-net.it> Date: Wed, 21 Feb 2007 20:06:03 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Hallvard B Furuseth Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CA818E.7090705@highlandsun.com> <45D098E8.5010703@highlandsun.com> <45D16117.3010207@novell.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hallvard B Furuseth wrote: > Jaimon Jose writes: >> Howard Chu wrote: >>> Fair enough. That just brings me back to my earlier point that there >>> 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. > > 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:-) 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. 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 From ldapext-bounces@ietf.org Wed Feb 21 14:07:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwo6-0000HO-9c; Wed, 21 Feb 2007 14:07:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwo4-0000Ee-DZ for ldapext@ietf.org; Wed, 21 Feb 2007 14:07:12 -0500 Received: from mail.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwo3-0006Mg-6v for ldapext@ietf.org; Wed, 21 Feb 2007 14:07:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id D8547162ADF; Wed, 21 Feb 2007 19:07:08 +0000 (GMT) Subject: Re: [ldapext] [Fwd: LDAP C API gripes] From: simo To: Pierangelo Masarati In-Reply-To: <45DC9414.7010706@sys-net.it> References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> <1172073139.11482.11.camel@localhost.localdomain> <45DC6CCF.6060100@highlandsun.com> <1172074277.11482.17.camel@localhost.localdomain> <20070221125226.3e54fb9e.mba2000@ioplex.com> <45DC9414.7010706@sys-net.it> Content-Type: text/plain Organization: Samba Team Date: Wed, 21 Feb 2007 14:07:08 -0500 Message-Id: <1172084828.11482.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: idra@samba.org List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Wed, 2007-02-21 at 19:48 +0100, Pierangelo Masarati wrote: > Michael B Allen wrote: > > > > As for retrieving the schema from the server at runtime, we did not do > > that. Not just for performance reasons but more so because there is no > > standard way to retrieve that information, it is awkward to do so or > > you cannot do it at all (e.g. RootDSE attributes in AD have no schema > > definitions). > > > There __is__ a standard way, it's described in RFC4512 secton 4.4; the > fact that some implementors don't comply with it, or do not populate > values as indicated in the standard is a totally different business. Last I checked AD supported subschemaSubentry, I don't think that changed overnight. I can't say the same of the std openLdap installation you find on many distributions out there :) I am not sure to what attributes Michael refer, but I guess that even if they are not defined they can be easily hard coded eventually. however, I am not really keen into entering a debate about standard implementations, I got some insight on what a client side validation API might be good at. I am still unsure if the benefits are enough to justify the added complexity but at least there is some substance there. Anyone have any other example of the benefits a client side API can bring? Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: idra@samba.org http://samba.org _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 14:22:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJx1u-0004W9-HL; Wed, 21 Feb 2007 14:21:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJx1s-0004Vl-Lj for ldapext@ietf.org; Wed, 21 Feb 2007 14:21:28 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJx1r-0001Gj-6w for ldapext@ietf.org; Wed, 21 Feb 2007 14:21:28 -0500 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJx1n-0007Tz-Jk; Wed, 21 Feb 2007 20:21:23 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx9.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJx1m-0007xx-VJ; Wed, 21 Feb 2007 20:21:23 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJx1m-0006R4-1e; Wed, 21 Feb 2007 20:21:22 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 21 Feb 2007 20:21:21 +0100 To: Pierangelo Masarati , jjaimon@novell.com Subject: Re: [ldapext] Dynamic group draft In-Reply-To: <45DB5B2E.3020702@sys-net.it> References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45DB47D8.8060305@novell.com> <45DB5B2E.3020702@sys-net.it> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.3, required=12.0, autolearn=disabled, AWL=0.681, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: C00929962CA5B4F2087BE0EB8B82D628F1D04719 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -42 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 4 max/h 3 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Haripriya S , Ldapext , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Pierangelo Masarati writes: >Jaimon Jose wrote: >>> 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. 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 14:52:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxUm-0004Q0-3y; Wed, 21 Feb 2007 14:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxUj-0004M7-Bt for ldapext@ietf.org; Wed, 21 Feb 2007 14:51:17 -0500 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJxS7-0006VG-NJ for ldapext@ietf.org; Wed, 21 Feb 2007 14:48:37 -0500 Received: from [192.168.1.199] (host40-89-static.72-81-b.business.telecomitalia.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id l1LJln3C027039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Feb 2007 20:47:50 +0100 Message-ID: <45DCA20C.60004@sys-net.it> Date: Wed, 21 Feb 2007 20:48:28 +0100 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.8 (X11/20061210) MIME-Version: 1.0 To: Hallvard B Furuseth Subject: Re: [ldapext] Dynamic group draft References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45DB47D8.8060305@novell.com> <45DB5B2E.3020702@sys-net.it> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00,SPF_FAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Hallvard B Furuseth wrote: > 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. Sorry, I'm not following you on this ground - but I must be missing something obvious. > 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? 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. 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 From ldapext-bounces@ietf.org Wed Feb 21 15:12:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxoV-0002UA-De; Wed, 21 Feb 2007 15:11:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxoU-0002U4-At for ldapext@ietf.org; Wed, 21 Feb 2007 15:11:42 -0500 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJxoS-0001oY-Ua for ldapext@ietf.org; Wed, 21 Feb 2007 15:11:42 -0500 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 3114E42BA2; Wed, 21 Feb 2007 15:12:02 -0500 (EST) Date: Wed, 21 Feb 2007 15:11:29 -0500 From: Michael B Allen To: idra@samba.org Subject: Re: [ldapext] [Fwd: LDAP C API gripes] Message-Id: <20070221151129.3fda349b.mba2000@ioplex.com> In-Reply-To: <1172084828.11482.53.camel@localhost.localdomain> References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> <1172073139.11482.11.camel@localhost.localdomain> <45DC6CCF.6060100@highlandsun.com> <1172074277.11482.17.camel@localhost.localdomain> <20070221125226.3e54fb9e.mba2000@ioplex.com> <45DC9414.7010706@sys-net.it> <1172084828.11482.53.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Wed, 21 Feb 2007 14:07:08 -0500 simo wrote: > On Wed, 2007-02-21 at 19:48 +0100, Pierangelo Masarati wrote: > > Michael B Allen wrote: > > > > > > > As for retrieving the schema from the server at runtime, we did not do > > > that. Not just for performance reasons but more so because there is no > > > standard way to retrieve that information, it is awkward to do so or > > > you cannot do it at all (e.g. RootDSE attributes in AD have no schema > > > definitions). > > > > > > There __is__ a standard way, it's described in RFC4512 secton 4.4; the > > fact that some implementors don't comply with it, or do not populate > > values as indicated in the standard is a totally different business. > > Last I checked AD supported subschemaSubentry, I don't think that > changed overnight. I can't say the same of the std openLdap installation > you find on many distributions out there :) Actually I'm wrong. Last time I looked at this I didn't think ADs subSchemaSubEntry had all of the necessary information. But looking at it again it apparently does. I think I was orignally concerned about not being able to filter by name. But an installer could download and store the defs for the library to load locally at runtime. I think that would perform pretty well especially if they were hash indexed by name. > I am not sure to what attributes Michael refer, but I guess that even if > they are not defined they can be easily hard coded eventually. The RootDSE attributes are not listed in subSchemaSubEntry or CN=Schema,CN=Configuration,DC=X under AD. Not sure why. I think it has something to do with bootstrapping the DIT. Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 15:24:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJy05-0004A4-Nw; Wed, 21 Feb 2007 15:23:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJy04-00048e-1L for ldapext@ietf.org; Wed, 21 Feb 2007 15:23:40 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJy02-0004WI-Nh for ldapext@ietf.org; Wed, 21 Feb 2007 15:23:40 -0500 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJy02-0008Gg-86; Wed, 21 Feb 2007 21:23:38 +0100 Received: from bombur.uio.no ([129.240.202.105]) by mail-mx9.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HJy01-0006qa-OU; Wed, 21 Feb 2007 21:23:37 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1HJy01-0006q1-K1; Wed, 21 Feb 2007 21:23:37 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 21 Feb 2007 21:23:37 +0100 To: Pierangelo Masarati Subject: Re: [ldapext] Dynamic group draft In-Reply-To: <45DCA20C.60004@sys-net.it> References: <45CA6D24.801@highlandsun.com> <45CCE420.4040600@sys-net.it> <45CE0F35.F25D.00B6.0@novell.com> <45DB47D8.8060305@novell.com> <45DB5B2E.3020702@sys-net.it> <45DCA20C.60004@sys-net.it> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.3, required=12.0, autolearn=disabled, AWL=0.667, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 56216B960E3F26E4F0648F4E55F6C48095CB8565 X-UiO-SPAM-Test: remote_host: 129.240.202.105 spam_score: -42 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 5 max/h 3 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org Pierangelo Masarati writes: >Hallvard B Furuseth wrote: >> 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. > > Sorry, I'm not following you on this ground - but I must be missing > something obvious. 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 ( 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Feb 21 16:54:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzPF-0000GA-B6; Wed, 21 Feb 2007 16:53:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzPD-0000Ft-G3 for ldapext@ietf.org; Wed, 21 Feb 2007 16:53:43 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJzPB-0001m7-IU for ldapext@ietf.org; Wed, 21 Feb 2007 16:53:42 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1LLrbck005186; Wed, 21 Feb 2007 16:53:38 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1LLraLT006314; Wed, 21 Feb 2007 16:53:37 -0500 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l1LLrZ6T021461; Wed, 21 Feb 2007 16:53:35 -0500 Message-ID: <45DCBF5E.3090902@redhat.com> Date: Wed, 21 Feb 2007 13:53:34 -0800 From: Pete Rowley User-Agent: Thunderbird 1.5.0.9 (X11/20061215) MIME-Version: 1.0 To: Kurt Zeilenga Subject: Re: [ldapext] [Fwd: LDAP C API gripes] References: <45D251C0.2050306@highlandsun.com> <45DC6997.5020906@highlandsun.com> <44F5C744-B0CD-4DDD-A437-5CDAD4749B8B@Isode.com> In-Reply-To: <44F5C744-B0CD-4DDD-A437-5CDAD4749B8B@Isode.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Hallvard B Furuseth , Ldapext X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0232344369==" Errors-To: ldapext-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0232344369== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050407030403090502050108" This is a cryptographically signed message in MIME format. --------------ms050407030403090502050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt Zeilenga wrote: > Another good reason to provide client side validation is to facilitate > conformance with the LDAP specification... RFC 4511, Section 4.1.5 > does say: > Clients MUST only send attribute values in a request that are valid > according to the syntax defined for the attributes. > > Of course, it's just wishful thinking that clients will actually > adhere to this MUST, which is why there are server side validation > requirements as well. It would certainly help clients to be more portable and deal with incompatibilities between servers, for example, servers which redefine standard attributes to be single valued etc., or that disagree in other ways about schema. Currently clients tend to be written to assume things about schema that reality reveals are not safe things to assume. -- Pete --------------ms050407030403090502050108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEDviSvktA94T6A8TxUShd9AwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTExNTA4MDUyMFoX DTA3MTExNTA4MDUyMFowRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEApRABgFPN60gQLIQRuuKGvf1ZEPfxgVykZrd3uIzpJ8ipQlQMujFQMIT+i6Q/ lBTwxDIncumO3HBJraWx8dUdimys4dG+zOsI0ajjO4TeIRMFkS9/njnsKbNH6j721WY+VuaZ FOYN0xcAOAKyaSrnHIl7N7PFF1VlUwGdd/QlzgBsXnFDIJrejBE0EDM9iXEVvnoDiMQQg81H 5O7ZZGl6ra04MT19hsYkdZFT/ajuD6+Rr5LjqoIE2vYlpBj5gL0z1Mg6NNygtOT91UQN4BVo YD4fx+PFAgcSxLo7TBM9DBftPAkgHsHlWWuVSXl0kbvO1ps/TRo31Y8yO463mrHEpQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOBgQA5oUNvfvaG1tRLI1BM8Pn3eENhvv6b8VR5aG07MXCsqhw5MNXkTzQx UMFCze6IMLecAt+zRYh0i09oeMJXudctJZCPXSRg4ygSDJ0dIVhz7v5ExIyEm5DCfzEBlIbl eP/3B4rADYzdlxa63n5akR2EvDkwi0/a2byeLU/MMk9LFDCCAt4wggJHoAMCAQICEDviSvkt A94T6A8TxUShd9AwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTExNTA4MDUyMFoXDTA3MTExNTA4MDUyMFowRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRABgFPN60gQ LIQRuuKGvf1ZEPfxgVykZrd3uIzpJ8ipQlQMujFQMIT+i6Q/lBTwxDIncumO3HBJraWx8dUd imys4dG+zOsI0ajjO4TeIRMFkS9/njnsKbNH6j721WY+VuaZFOYN0xcAOAKyaSrnHIl7N7PF F1VlUwGdd/QlzgBsXnFDIJrejBE0EDM9iXEVvnoDiMQQg81H5O7ZZGl6ra04MT19hsYkdZFT /ajuD6+Rr5LjqoIE2vYlpBj5gL0z1Mg6NNygtOT91UQN4BVoYD4fx+PFAgcSxLo7TBM9DBft PAkgHsHlWWuVSXl0kbvO1ps/TRo31Y8yO463mrHEpQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA5oUNv fvaG1tRLI1BM8Pn3eENhvv6b8VR5aG07MXCsqhw5MNXkTzQxUMFCze6IMLecAt+zRYh0i09o eMJXudctJZCPXSRg4ygSDJ0dIVhz7v5ExIyEm5DCfzEBlIbleP/3B4rADYzdlxa63n5akR2E vDkwi0/a2byeLU/MMk9LFDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQO+JK+S0D 3hPoDxPFRKF30DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNzAyMjEyMTUzMzRaMCMGCSqGSIb3DQEJBDEWBBRrQG/nYi10iKtb cN3BEqnbxRaDWjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDvi SvktA94T6A8TxUShd9AwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDviSvktA94T6A8TxUShd9AwDQYJKoZIhvcN AQEBBQAEggEAZhdPjt5K2dvRMBqGr+0pYgifGpXcUsIZQWOG4Zglp300+3noCMPG4Ro8jgiM FwhJ5HG6zRgO+HVQKApuqyJkIqq0/vzrlquvl87nF5h1HpbzZyPwbaF0Ik2yCF+7hVvkz9cY 60qa6C+XrmYquWEdq82JGkVL7LuVoJ379NTSGfAvfh3ERVZFDkV9dSLVAQ8BYdw+ngmGRLxX I1PH2EicwiSFHQeL9bIz4+VR3q82w8FLG7IJ2UAm/GWAfvp9CCU/iyeT86fbMhiOdUTGo2yq Mc0OAKQFxmOExbDl6VnbAGRpa6aSMtYmEPcA2jM72P/ct9TpOFStsNwJp7jFNErRnwAAAAAA AA== --------------ms050407030403090502050108-- --===============0232344369== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0232344369==--