Re: slapo-dynlist search member=value search?

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

Aleksander Adamowski wrote:

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

No, one is enough for functionality.  The reverse is not strictly required.

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

Then it's not designed to exploit LDAP groups.

> I believe that nss_ldap also does both types of search.

No it doesn't.  It is designed check presence of user's DN in 
well-specified groups.

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

Yes it does.  If a DN is found to be member of a group within the 
lifespan of an operation, so that the identity that performed the 
membership check doesn't change, membership information is cached, 
mainly to improve access checking efficiency.

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

What you're thinking of is not implemented in OpenLDAP.  If you think 
it's so easy and so much required, feel free to submit a patch.  Patches 
that provide generally useful functionalities are always welcome.

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