Dynamic Group Support for mod_authnz_ldap

I am willing to contribute a patch to mod_authnz_ldap to
enable it to do 
dynamic group lookup (basically there are attributes in a
group entry 
whose values are LDAP URIs that describe a search that will
contain 
group members).

My feature request and initial patch are at 
http://issues.apache.org/bugzilla/show_bug.cgi?id=38515, but I would 
like some more input before I make a final drive at
completing the 
modification.

Some of my questions are:

*What needs to be customizable?  The 'memberURL' attribute
that contains 
LDAP URI's is pretty universal, but I'm not sure if it is
a standard or 
if other LDAP implementation use something else.

*How robust should the processing be of the returned LDAP
URI's?  It 
might be theoretically possible for the URI to reference
another LDAP 
server and hence the need to establish another connection! 
Is it worth 
doing this?  Is this even a common occurrence?

*To whom can I direct specific questions regarding
mod_authnz_ldap and 
util_ldap?

Thank you for your time,

Gregory Szorc
gregory.szorccase.edu

On Fri, March 31, 2006 8:43 am, Gregory Szorc said:

> *What needs to be customizable?  The 'memberURL'
attribute that contains
> LDAP URI's is pretty universal, but I'm not sure if
it is a standard or
> if other LDAP implementation use something else.
>
> *How robust should the processing be of the returned
LDAP URI's?  It
> might be theoretically possible for the URI to
reference another LDAP
> server and hence the need to establish another
connection!  Is it worth
> doing this?  Is this even a common occurrence?

I'd say it would be worth doing if practical, you never
know how it might
be used in future.

> *To whom can I direct specific questions regarding
mod_authnz_ldap and
> util_ldap?

This mailing list.

Regards,
Graham,
--

Graham Leggett wrote:
  >> *To whom can I direct specific questions
regarding mod_authnz_ldap and
>> util_ldap?
> 
> This mailing list.

Alright then.  I have some rather specific implementation
questions:

Do we want the "require ldap-group" directive to
handle both static and 
dynamic groups, or do we want a new directive, say
"require 
ldap-dynamicgroup"?

If extending the functionality of "require
ldap-group," do we want 
dynamic group lookups enabled by default (as a fall back) or
do we want 
a config directive to enable them?  A performance caveat of
dynamic 
groups is they require a ldap search for the dynamic group
attribute 
(but this could be cacheable).

Is it possible to cache the output of the search that
obtains the 
dynamic group attributes from a group DN?  Looking at the
debugger, I 
can see util_search_node_t has a "vals" member,
but I can't seem to 
produce any multi-valued cache searches.  Can someone give
me some 
pointers on where to find some code that has multi-valued
cache storage 
and searches?

For the overall caching support, I see there are 3 cache
nodes:  search, 
compare, and dn_compare.  I assume I can cache the search
for dynamic 
group member URL's using the search cache.  However, there
are two 
choices for caching the dynamic group membership lookup
result.  1) Use 
the compare cache.  The result of the dynamic group lookup
is stored in 
the compare cache under the DN of the original group.  Then,

uldap_cache_compare, which is called by existing
"require ldap-group" 
code will find this cached result and we don't have to
worry about 
executing dynamic group code.  2) Use the search cache. 
Since dynamic 
groups are given by LDAP URI's that reference a search,
this seems more 
logical, however incurs a little more overhead since the
existing 
"require ldap-group" code would not handle
dynamic groups.  In my 
opinion, if we were to extend "require
ldap-group", then method 1. makes 
sense, whereas a separate directive dictates method 2.

If someone could comment on the existing patch I have at 
http://issues.apache.org/bugzilla/show_bug.cgi?id=38515, it would be 
much appreciated.  I am a first-time HTTPD contributer and
want to make 
sure I am on the right track.

Gregory Szorc
gregory.szorccase.edu