Issue 5305 - Contribware: Two overlays for implementing NESTED dynamic groups
Summary: Contribware: Two overlays for implementing NESTED dynamic groups
Status: VERIFIED SUSPENDED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: contrib (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-03 20:29 UTC by josemarcodelarosa@gmail.com
Modified: 2021-08-03 17:49 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description josemarcodelarosa@gmail.com 2008-01-03 20:29:02 UTC
Full_Name: Jose Marco de la Rosa
Version: 2.3.39
OS: Kubuntu 7.10
URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz
Submission from: (NULL) (80.25.122.131)


Two overlays that implement dynamic group classes defined with URL attributes
and allowing nesting.

- The first one is an extension of th overlay expandURL but allowing nesting

- The second one changes the way groups are constructed in a more powerful way

Examples of functioning follow for each version and are included in the
overlays
code archives (.c)

The tarball Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz was uploaded
to openldap's server and it includes a webpage with further detail in the
implementation and configuration of the overlay.

Code files are appropriately linked in the web page mentioned (all is included
in the tarball: there are no external references in the webpage).

Both search and compare operations were implemented

I hope you like it...

#######################################################
First overlay: nestedAggregateAttrDN:

* SYNTAX:
 * 
 * In slapd.conf :
 *   overlay nestedAggregateAttrDN
 *   nestedAggregateAttrDN  <objectClass> <source-attribute>
<destination-attribute> [[<maximum-depth>] <TTL>]
 * Where:
 *      <objectClass> specifies the class that should expand.
 *      <source-attribute> establishes the attribute that contains information 
 *              about other entries where to gather destination attribute values
from.
 *      <destination-attribute> establishes the attribute that should present
all the gathered values.
 *      <maximum-depth> establishes the maximum nesting depth level. If not
specified, it defaults 
 *              to 0 which means no nesting is allowed (not even one level).
 *      <TTL> establishes the maximum time allowed to serve the query. You
should take into account that:
 *            If different TTLs are set for the different configurations the
minimum 
 *            will be used for all configurations.
 *            The TTL affects ALL searches done when the overlay is active and
not only 
 *            those related to the configured clases.
 * 
 * 
 * EXAMPLE:
 * 
 * NOTE: you will probably need/want to define some attributes and classes in
your schema
 * example.schema:
 * -------------------
 * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber>
 * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3
 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1
 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2
 * 
 * # Attribute type for new classes
 * 
 * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1
 *  NAME 'subgroupDN'
 *  DESC 'DN of a aggregable entry'
 *  SUP distinguishedName )
 *
 * # Classes for using overlay nestedAggregateAttrDN
 * 
 * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1
 * 	NAME 'subgroupedDNGroup'
 * 	DESC 'Sample class for nestedAggregateAttrDN (experimental purpose)'
 * 	SUP top STRUCTURAL
 * 	MUST cn
 * 	MAY ( member $ subgroupDN $ cn $ ou $ o $ description ) ) 
 * 
 * 
 * slapd.conf:
 * -------------------
 * overlay nestedAggregateAttrDN
 * # Configure class: subgroupedDNGroup
 * # Source attribute: subgroupDN
 * # Aggregated attribute: member
 * # Max depth in nesting: 4
 * # TTL: 5 sec
 * nestedAggregateAttrDN  subgroupedDNGroup subgroupDN member 4 5
 *  
 * 
 * ldif:
 * -------------------
 * 
 * # Static1
 * dn: cn=Static1,dc=test
 * cn: Static1
 * objectClass: groupOfNames
 * member: cn=person1,dc=test
 * member: cn=person2,dc=test
 * 
 * # Static2
 * dn: cn=Static2,dc=test
 * cn: Static2
 * objectClass: groupOfNames
 * member: cn=person3,dc=test
 * member: cn=person4,dc=test
 * 
 * # SubgroupedLevel1
 * dn: cn=SubgroupedLevel1,dc=test
 * cn: SubgroupedLevel1
 * objectClass: subgroupedDNGroup
 * subgroupDN: cn=Static1,dc=test
 * 
 * # SubgroupedLevel2
 * dn: cn=SubgroupedLevel2,dc=test
 * cn: SubgroupedLevel2
 * objectClass: subgroupedDNGroup
 * subgroupDN: cn=SubgroupedLevel1,dc=test
 * subgroupDN: cn=Static2,dc=test
 * 
 * 
 * -------------------
 * 
 * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return
 * 
 * # SubgroupedLevel2
 * dn: cn=SubgroupedLevel2,dc=test
 * cn: SubgroupedLevel2
 * objectClass: subgroupedDNGroup
 * subgroupDN: cn=SubgroupedLevel1,dc=test
 * subgroupDN: cn=Static2,dc=test
 * member: cn=person1,dc=test
 * member: cn=person2,dc=test
 * member: cn=person3,dc=test
 * member: cn=person4,dc=test
 *
 * 
 * IMPORTANT: this overlay conflicts with nestedAggregateAttrURL.
 * 		if both are active, some searches don't behave as expacted!
 * 		Specifically, if you turn both overlays on and search for
 * 		'entries with member=<some member value>' won't work properly
 * 		for one of the overlays (the firstly activated one)
 */  


#######################################################
Second overlay: nestedAggregateAttrURL:

 * SYNTAX:
 * 
 * In slapd.conf :
 *   overlay nestedAggregateAttrURL
 *   nestedAggregateAttrURL  <objectClass> <source-attribute>
<destination-attribute> [[<maximum-depth>] <TTL>]
 * Where:
 *      <objectClass> specifies the class that should expand.
 *      <source-attribute> establishes the attribute that contains information 
 *              about other entries where to gather destination attribute values
from.
 *      <destination-attribute> establishes the attribute that should present
all the gathered values.
 *      <maximum-depth> establishes the maximum nesting depth level. If not
specified, it defaults 
 *              to 0 which means no nesting is allowed (not even one level).
 *      <TTL> establishes the maximum time allowed to serve the query. You
should take into account that:
 *            If different TTLs are set for the different configurations the
minimum 
 *            will be used for all configurations.
 *            The TTL affects ALL searches done when the overlay is active and
not only 
 *            those related to the configured clases.
 * 
 * 
 * EXAMPLE:
 * 
 * NOTE: you will probably need/want to define some attributes and classes in
your schema. You can use
 * 		netscape's groupOfURLs, anyway...
 * example.schema:
 * -------------------
 * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber>
 * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3
 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1
 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2
 * 
 * # Attribute type for new classes
 * 
 * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1
 *  NAME 'subgroupURL'
 *  DESC 'URL to search for aggregable entries'
 *  SUP labeledURI )
 *
 * # Classes for using overlay nestedAggregateAttrURL
 * 
 * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1
 * 	NAME 'subgroupedURLGroup'
 * 	DESC 'Sample class for nestedAggregateAttrURL (experimental purpose)'
 * 	SUP top STRUCTURAL
 * 	MUST cn
 * 	MAY ( member $ subgroupURL $ cn $ ou $ o $ description ) ) 
 *  
 * attributetype ( IAVANTE_LDAPattributeType:2
 * 	NAME 'subgroupURL'
 * 	DESC 'Identifies an URL containing a search for names of subgroups.'
 * 	SUP labeledURI )
 * 
 * 
 * slapd.conf:
 * -------------------
 * overlay nestedAggregateAttrURL
 * # Configure class: subgroupedURLGroup
 * # Source attribute: memberURL
 * # Aggregated attribute: member
 * # Max depth in nesting: 4
 * # TTL: 5 sec
 * nestedAggregateAttrURL  subgroupedURLGroup subgroupURL member 4 5
 * 
 * 
 * ldif:
 * -------------------
 * 
 * # Static1
 * dn: cn=Static1,dc=test
 * cn: Static1
 * objectClass: groupOfNames
 * member: cn=person1,dc=test
 * member: cn=person2,dc=test
 * 
 * # Static2
 * dn: cn=Static2,dc=test
 * cn: Static2
 * objectClass: groupOfNames
 * member: cn=person3,dc=test
 * member: cn=person4,dc=test
 * 
 * # SubgroupedLevel1
 * dn: cn=SubgroupedLevel1,dc=test
 * cn: SubgroupedLevel1
 * objectClass: subgroupedURLGroup
 * subgroupURL: ldap:///dc=test??one?(cn=Static*)
 * 
 * # SubgroupedLevel2
 * dn: cn=SubgroupedLevel2,dc=test
 * cn: SubgroupedLevel2
 * objectClass: subgroupedURLGroup
 * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test
 * 
 * 
 * -------------------
 * 
 * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return
 * 
 * # SubgroupedLevel2
 * dn: cn=SubgroupedLevel2,dc=test
 * cn: SubgroupedLevel2
 * objectClass: subgroupedURLGroup
 * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test
 * member: cn=person1,dc=test
 * member: cn=person2,dc=test
 * member: cn=person3,dc=test
 * member: cn=person4,dc=test
 *
 * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN.
 * 		if both are active, some searches don't behave as expacted!
 * 		Specifically, if you turn both overlays on and search for
 * 		'entries with member=<some member value>' won't work properly
 * 		for one of the overlays (the firstly activated one)
 * 
 */  

Comment 1 Howard Chu 2008-01-03 22:46:14 UTC
josemarcodelarosa@gmail.com wrote:
> Full_Name: Jose Marco de la Rosa
> Version: 2.3.39
> OS: Kubuntu 7.10
> URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz
> Submission from: (NULL) (80.25.122.131)
> 
> 
> Two overlays that implement dynamic group classes defined with URL attributes
> and allowing nesting.
> 
> - The first one is an extension of th overlay expandURL but allowing nesting
> 
> - The second one changes the way groups are constructed in a more powerful way

>  * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN.
>  * 		if both are active, some searches don't behave as expacted!
>  * 		Specifically, if you turn both overlays on and search for
>  * 		'entries with member=<some member value>' won't work properly
>  * 		for one of the overlays (the firstly activated one)

Seems there's really no need for the nestedAggregateAttrDN overlay, since that 
is just a proper subset of a URL. I.e., anywhere you would use a simple DN is 
just a case of subGroupURL: ldap:///<dn>??base

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

Comment 2 josemarcodelarosa@gmail.com 2008-01-04 13:07:36 UTC
  Yes, you are completely right.  The only reason I can think of using the
DN version is because you are forced by your schema (attribute types for the
expansion source attribute differ). I emphasize that the implementation of
both is quite different. The DN version uses recursivity while the URL
version relies in slapd's search-reply mechanism. I just added the first one
as an example.

  URL version is much more powerful and more elegant. You suggested
subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok
(if I remember right).
Comment 3 ando@openldap.org 2008-01-05 10:15:50 UTC
josemarcodelarosa@gmail.com wrote:

>   Yes, you are completely right.  The only reason I can think of using the
> DN version is because you are forced by your schema (attribute types for the
> expansion source attribute differ). I emphasize that the implementation of
> both is quite different. The DN version uses recursivity while the URL
> version relies in slapd's search-reply mechanism. I just added the first one
> as an example.
> 
>   URL version is much more powerful and more elegant. You suggested
> subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok
> (if I remember right).

According to Section 3 of RFC 4516, if <scope> is omitted, a scope of
"base" is assumed.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
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
---------------------------------------


Comment 4 ando@openldap.org 2008-01-05 11:40:00 UTC
Jose,

few preliminary comments:

- you coded your contribution for OpenLDAP 2.3; however, since it
configures as a new feature, it should be coded for OpenLDAP 2.4 (better
for HEAD), as 2.3 is feature-frozen ever since.  This comment may appear
trivial, but right now your contribution does not compile with HEAD/re24
because of some internal API changes.

- the coding style you used does not conform to that of the OpenLDAP
project.  Although this is usually only loosely enforced, you used
things we're a bit picky about, like C++-style comments, and late
declarations; if you compile with enough warnings (e.g., with gcc, with
-Wall -pedantic) you'll see that in many cases functions are not
returning when a return value is expected or vice-versa; incorrect
formats are used for (long) integers, pointers and so.  Also, I note
that besides being a totally new contribution, many of the comments are
already no longer aligned with the code.

- according to agreed development lines, new contributions should always
provide back-config support (this can be added later, if and when the
rest works as expected)

- with respect to the possible improvements you indicate, I think:
  1) permission checking should occur along the lines of, e.g.,
slapo-dynlist(5), honoring dgIdentity and dgAuthz.
  2) avoiding unnecessary expansion would probably be mandatory for
production use
  3) use back-config rather than naive in-database configuration using
an ordinary database

- The build instructions you provide are incorrect: you suggest to place
the source in servers/slapd/overlays/, and to modify statover.c; this is
a generated file, so it should never be modified.  You should rather
suggest to place the sources in an arbitrary directory (it could be
contrib/slapd-modules/nestedAggregateAttr as soon as your contribution
enters the official distribution) and build it as a run-time module.

- you should rather eliminate duplicate values from result sets (much
like slapo-dynlist(5) does) as they are not allowed by the definition of
the "member" attribute, which has a distinguishedNameMatch EQUALITY rule.

- instead of copying compare_entry(), you should rather ask to make the
one in servers/slapd/compare.c non-static

- since the "OR" operator in filters allows more than 2 operands, I
think your filter combination strategy could be optimized by simply
defining a combine_filters() function that counts the number of filter
strings in the array and creates a filter like "(|(f1)(f2)(f3)...)"

- in check_filter(), you compare strings; you should rather compare
pointers to AttributeDescription structures.

- in nestedAggregateAttrURL_search() you don't need to run str2filter()
on op->ors_filterstr, since an exploded filter is already available in
op->ors_filter

- strings[] containing "(objectClass=<ocname>)" could be prepared once
for all during config; it would save a lot of mallocs (BTW: use the slab
for operation-spanning allocation).

- I would recommend you do some consistent checking of return values
before dereferencing pointers.

- I would recommend that you either remove or turn into useful standard
debugging the plethora of non-standard messages you added.  Use
LDAP_DEBUG_ARGS to mark entering/exiting functions (and logging useful
args); use LDAP_DEBUG_TRACE to trace operations; use slap_loglevel_get()
to register friendly names for specific log subsystems (you'll get back
the number to compare with ldap_debug).

- with respect to the OID for the test schema items, you'll get an OID
arc in the experimental OID namespace of the OpenLDAP project as soon as
your contribution is incorporated.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
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
---------------------------------------


Comment 5 ando@openldap.org 2008-01-11 18:33:35 UTC
changed notes
changed state Open to Feedback
Comment 6 ando@openldap.org 2008-01-22 19:46:36 UTC
From a private message the contributor sent me, it appears he's not
working at this any more, and he doesn't intend to take care of the
reviews.  So I suggest his contribution goes to "contrib", in case
anyone finds it useful.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
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
---------------------------------------


Comment 7 Howard Chu 2008-01-23 15:33:01 UTC
moved from Incoming to Contrib
Comment 8 Kurt Zeilenga 2008-03-04 05:55:27 UTC
changed notes
Comment 9 Kurt Zeilenga 2008-03-04 05:57:28 UTC
changed notes
changed state Feedback to Suspended
Comment 10 OpenLDAP project 2014-08-01 21:03:27 UTC
IPR okay
under review
Comment 11 Quanah Gibson-Mount 2021-08-03 17:49:37 UTC
Fixed with openldap 2.5 dynlist?