наложение прокси-кеша на slapd (proxy cache overlay to slapd)
Предостережение (Caveat)
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 pcacheTemplate
TTL. These inconsistencies can be minimized by careful use of
the TTR.
The proxy cache overlay requires a full result set of data to
properly function. Therefore it will strip out the paged results
control if it is requested by the client.
The remote server should expose the objectClass attribute because
the underlying database that actually caches the entries may need
it for optimal local processing of the queries.
The proxy server should contain all the schema information
required for caching. Significantly, it needs the schema of
attributes used in the query templates. If the objectClass
attribute is used in a query template, it needs the definition of
the objectClasses of the entries it is supposed to cache. It is
the responsibility of the proxy administrator to keep the proxy
schema lined up with that of the proxied server.
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 back-ldap, proxy caching be used in
conjunction with the identity assertion feature of slapd-ldap(5)
(see the idassert-bind and the idassert-authz statements), so
that remote server interrogation occurs with a vanilla identity
that has some relatively high search and 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.
