[Date Prev][Date Next]
Re: slapo-dynlist search member=value search?
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
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
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.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172