Re: slapo-dynlist search member=value search?

[Aleksander Adamowski <aleksander.adamowski@altkom.pl>]

Pierangelo Masarati pisze:
> You can't put in the filter information that has to be generated 
> dynamically, like dynamic group membership.  Or, you could, but then 
> any search would need to be split into:
>
> - search the whole database for (objectClass=*) to trigger dynamic 
> expansion of data; then
> - search the (at this point, unindexed) dynamically generated data. 
> This could be implemented, but probably it's not what users want...
I thought that it works exactly like this, and I think this is what 
users want and expect (e.g. see the post "Dynamic Group overlay with 
ldapsearch for uniquemember oddity" from march 2006 by Michael Heep).

Groups are almost unusable if they don't work both ways since the 
necessary operations for a group-based authorization subsystem are both: 
mapping a group to member users and mapping a user to groups he's a 
member of.

For example, see Zope/Plone LDAP Multi Plugin 
(http://plone.org/products/ploneldap): it needs the following 
functionalities for LDAP groups to work properly (the names should be 
self-explanatory): enumerateGroups, getGroupsForPrincipal, enumerateUsers.

I believe that nss_ldap also does both types of search.

I imagined that OpenLDAP maintained a cache for dynamic groups (that's 
how I understood "this exploits slapd group caching capabilities" in the 
FAQ) in order to do a search on (member=member'sDN).
Such a cache would only need updating in only two cases:

  1. when there's a change in an object's DN if the object has an
     attribute used in any memberURL
  2. when there's a change in any object in any attribute that's used
     in a filter in any memberURL in the directory (sorry for
     convoluted sentence, but it's a convoluted subject...).


When I think about it, this data should be permanent, so it should be 
kept in an index, not in memory cache.

Yes, there's some complex logic involved here (e.g. there needs to be a 
list kept updated with names of all the attributes that are used in 
memberURL filters) and it cannot posibly work for non-local memberURLs 
(those that specify a different LDAP server). But this is theoretically 
possible and would make dynlist usable for group memberships, not only 
for mail aliases (like currently).


--
Best Regards,
   Aleksander Adamowski
       GG#: 274614
       ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
   Administrator systemów korporacyjnych; Instruktor
   Altkom Akademia S.A. http://www.altkom.pl
   Warszawa, ul. Chłodna 51
   
   kom. 0-601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete all copies of this message.