[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Proxy cache extension for OpenLDAP

Kurt D. Zeilenga writes:

At 03:08 AM 2002-09-06, Howard Chu wrote: 
From: Apurva Kumar [mailto:kapurva@in.ibm.com]
LDAP proxy cache docs in HTML.


Thanks. It's a fascinating idea. The effect of ACLs on cached results isn't
considered though; I guess you assume that all clients of the proxy will have
equal privileges on the remote server. (That's a fair enough assumption for
many scenarios, it just needs to be stated.)

You should be able to apply per-user ACLs on information
held in the cache, but use another identity in obtaining
information for the cache. 

That is, caching aside, back-ldap should be able to obtain
information using a common identity but return it only if
it matches per-user ACLs.

Although feasible (and surely interesting) this doesn't ensure
the same rights of the source are applied by the caching proxy
(I realize the same applies to replicas; at this point it is
unclear to me what's the difference between a proxy and a
(partial?) replica.

This becomes interesting if applied to a sort of metadirectory
that is complementary to back-meta: imagine a connector that
builds entries merging attributes from different sources,
possibly caching the entries; it should contain rules to
transform a DN into ldap searches to different targets,
possibly remapping the base, the attributes and the objectclasses.
When I investigated it, one major problem was filter splitting;
Apurva's idea of creating templates sound interesting; otherwise
we'd need to rebuild the entire "merged" database in-memory and
apply the filter to the resulting entry. I note that this would
be necessary only every now and then if appropriate caching
(and in-memory or on a cache db indexing) is performed.
In this case it is reasonable to assume that entry build-up
is performed by connecting to the sources as an administrative
user, and appropriate ACLs are enforced at the connector side. 



You can implement your cache_backend APIs without directly modifying
back-ldbm.

Apurva and discussed the need to support back-bdb as the cache
store. Your suggestion seems like a reasonable approach for
not only providing back-bdb support, but allowing any backend
to serve as the cache store. 

Also, there should be some kind of cache aging parameter to eliminate stale
data from the cache.

Likely some sort of default TTL augmented by entry TTLs would
cover this well enough. 

It's a very good effort. I think the query containment and query template
approach makes sense. Hopefully some more folks will examine this patch and
chime in.

I'll look at it (hopefully soon). I'd like to see something
similar for back-meta.

Ando.


Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati