.TH SLAPO-PCACHE 5 "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" Copyright 1998-2004 The OpenLDAP Foundation, All Rights Reserved.
+.\" Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved.
.\" Copying restrictions apply. See the COPYRIGHT file.
.\" Copyright 2001, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
.\" $OpenLDAP$
attributes. The \fBtemplate string\fP for a query can be obtained by
removing assertion values from the RFC 2254 representation of its search
filter. A query belongs to a template if its template string and set of
-projected attributes correspond to a cacheable template. Examples of template strings are (mail=), (|(sn=)(cn=)), (&(sn=)(givenName=)).
+projected attributes correspond to a cacheable template.
+Examples of template strings are \fB(mail=)\fP, \fB(|(sn=)(cn=))\fP,
+\fB(&(sn=)(givenName=))\fP.
.LP
+The config directives that are specific to the
+.B proxycache
+overlay can be prefixed by
+.BR proxycache\- ,
+to avoid conflicts with directives specific to the underlying database
+or to other stacked overlays. This may be particularly useful for those
+directives that refer to the backend used for local storage.
The following cache specific directives can be used to configure the proxy
cache:
.TP
-.B overlay proxycache
-This directive adds the proxycache overlay to the current backend. The
-proxycache overlay may be used with any backend but is intended for use
+.B overlay pcache
+This directive adds the proxy cache overlay to the current backend. The
+proxy cache overlay may be used with any backend but is intended for use
with the
.BR ldap ,
.BR meta ,
Specifies a cacheable template and "time to live" (in sec) <ttl> of queries
belonging to the template.
+.TP
+.B response-callback { head | tail }
+Specifies whether the response callback should be placed at the
+.B tail
+(the default) or at the
+.B head
+(actually, wherever the stacking sequence would make it appear)
+of the callback list. This affects how the overlay interacts with other
+overlays, since the proxycache overlay should be executed as early
+as possible (and thus configured as late as possible), to get
+a chance to return the cached results; however, if executed early
+at response, it would cache entries that may be later "massaged"
+by other databases and thus returned \fIafter\fP massaging the first
+time, and \fIbefore\fP massaging when cached.
+
+.TP
+There are some constraints:
+
+all values must be positive;
+
+.B <entry_limit>
+must be less than or equal to
+.BR <max_entries> ;
+
+.B <numattrsets>
+attribute sets SHOULD be defined by using the directive
+.BR proxyattrset ;
+
+all attribute sets SHOULD be referenced by (at least) one
+.B proxytemplate
+directive;
+
.LP
-The following adds a template with filter string (&sn=)(givenName=)) and attributes mail, postaladdress, telephonenumber and a TTL of 1 hour.
+The following adds a template with filter string \fB((&sn=)(givenName=))\fP
+and attributes mail, postaladdress, telephonenumber and a TTL of 1 hour.
.LP
.RS
.nf
proxytemplate \fB(&(sn=)(givenName=)) 0 3600\fP
.fi
.RE
+
.LP
Directives for configuring the underlying database must also be given, as
shown here:
.RE
.LP
Any valid directives for the chosen database type may be used.
+.SH CAVEATS
+Caching data is prone to inconsistencies because updates on the remote server
+will not be reflected in the response of the cache at least (and at most)
+for the duration of the
+.B proxytemplate
+.BR TTL .
+
+The remote server should expose the
+.B objectClass
+attribute because the underlying database that actually caches the entries
+may need it for optimal local processing of the queries.
+
+Another potential (and subtle) inconsistency may occur when data is retrieved
+with different identities and specific per-identity access control
+is enforced by the remote server.
+If data was retrieved with an identity that collected only partial results
+because of access rules enforcement on the remote server, other users
+with different access privileges on the remote server will get different
+results from the remote server and from the cache.
+If those users have higher access privileges on the remote server, they will
+get from the cache only a subset of the results they would get directly
+from the remote server; but if they have lower access privileges, they will
+get from the cache a superset of the results they would get directly
+from the remote server.
+Either occurrence may or may not be acceptable, based on the security policy
+of the cache and of the remote server.
+It is important to note that in this case the proxy is violating the security
+of the remote server by disclosing to an identity data that was collected
+by another identity.
+For this reason, it is suggested that, when using
+.BR back-ldap ,
+proxy caching be used in conjunction with the
+.I identity assertion
+feature of
+.BR slapd-ldap (5)
+(see the
+.B idassert-bind
+and the
+.B idassert-authz
+statements), so that remote server interrogation occurs with a vanilla identity
+that has some relatively high
+.B search
+and
+.B read
+access privileges, and the "real" access control is delegated to the proxy's ACLs.
+Beware that since only the cached fraction of the real datum is available
+to the cache, it may not be possible to enforce the same access rules that
+are defined on the remote server.
+When security is a concern, cached proxy access must be carefully tailored.
.SH FILES
+
.TP
ETCDIR/slapd.conf
default slapd configuration file
.BR slapd\-ldap (5),
.BR slapd\-meta (5),
.BR slapd\-sql (5),
-.BR slapd (8),
-.BR regex (7).
+.BR slapd (8).
.SH AUTHOR
Originally implemented by Apurva Kumar as an extension to back-meta;
turned into an overlay by Howard Chu.