Re: commit: ldap/servers/slapd/overlays pcache.c

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

> > I think that the access control aspect of the proxy cache in relation to
> > back-ldap needs to be elaborated further. Suppose a situation where the
> > proxy cache stores search entries from the searches having the same
search
> > spec but requested by distinct identities. From the next search, the
> > request
> > will be satisfied by the internal database if they are answerable.
Unless
> > we
> > have the same access control in the proxy cache as in the remote server,
a
> > search  can return entries originally prohibited by the target server. I
> > also suspect that proxyAuthz is required for the proxy cache when it
needs
> > to deal with clients having different access control.
>
> What you're depicting is a scenario where the cached search is done by the
> proxy with some special identity that ensures a broad access, and
> subsequent operations on the cached data are performed locally based on
> the client's identity by means of the local access control rules.  This is
> a very specific scenario that implies a trust relation ship between the
> remote server and the proxy, so that the remote server is willing to give
> broad access to the proxy itself and delegate access control to the proxy.
>  In this case, the cahced request is performed with an administrative
> identity.  I see other possibilities:
>
> a) remote requests are performed by the proxy under an administrative
> identity, cached once for all and then satisfied locally based on the
> client's identity by locally applying acces rules.
> b) remote requests are performed with the client's identity (either by
> binding as the client or by asserting its identity), and cached on a
> per-client basis; access control is directly applied by the remote server,
> and for a client only data it can access is cached.
>
> On the one hand, the latter approach may lead to a proliferation of the
> cached data, but it does not require the remote server to trust the proxy
> and delegate access control.  From my understanding, this latter was the
> approach of proxycache, at least before it made it into an overlay.  Note
> that I'm not favoring any of the approaches (there might even be more,
> with overlappings); they're both reasonable, and may apply to specific
> scenarios.

(b) can be viewed as the current method by and large but there're
differences:
      - It is not crystal clear what you meant by the caching on a
         per-client basis, but it seems to me that the pcache caching
         is not performed on a per-client basis.
      - Hence, if multiple clients having different access controls
         accessed the remote target server, the proxy cache will cache
         their aggregate result. Without the same access control set up
         at the proxy cache, a client can access data in the proxy cache
         which are not allowed in the remote target server.
(a) can be in fact viewed as a replica-initiated replication.
- Jong-Hyuk