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

["Pierangelo Masarati" <ando@sys-net.it>]

Apurva,

I need to examine the code more carefullybefore I can reply to your
suggestions.  I'm not sure a reasonable "identity containment" rule can be
written.  My concern is that if I make the cache stick with one identity,
what should be the behavior when some other identity performs a query that
is contained in a cached one?  The query would be ANSWERABLE except for
the identity, so it would need to becoem CACHEABLE (i.e. require a direct
search to the remote server) and either it is cached in place of the
existing one, or it is not cached at all, leaving the existing one in
place.  Is my analysis correct?

Ciao, p.

>
>
>
>
>
>
> owner-openldap-devel@OpenLDAP.org wrote on 11/18/2004 03:01:47 AM:
>
>> ando@OpenLDAP.org wrote:
>>
>> >Log Message:
>> >the caching database may need to inherit ACLs and limits from the proxy
>> >
>> >
>>
>> FYI, I needed the above to ensure the cache honors ACLs at the proxy
>> side.  I think there are few other issues with pcache; essentially:
>> 1) the cache has no knowledge of the identity that was used to populate
>> it; this can be an issue if clients authenticate as individual users
>> instead of asserting an applicative identity and if per-user ACLs are
>> enforced at the remote server.  I don't see an easy fix to this, except
>> a per-user cache; I think this was already discussed at some point.
>
> Rather than having the cached data stored on a per-user basis, it should
> be
> possible to perform identity checks during query containment. Currently
> the
> meta-data for each cached query (search request) stores the base, scope,
> filter and projected attributes. If the bind DN of the user which
> requested
> the cached query and the list of attribute names for returned attributes
> (subset of projected attributes) are also stored as query meta-data, then
> it is possible to enforce backend server ACLs by:
> (i) Answering a query Q from a cached query Q' only if the
> bindDN(Q)=bindDN(Q') AND Q is (semantically) contained in Q'.
> (ii) Performing the search on the shared cache but not returning any
> attributes which were not returned (by the backend server) for Q'.
>
> The above assumes that proxy can authenticate the user and asserts the
> client's identity when requesting data from backend server.
>
> Of course, the ACLs at the backend could change in the time between Q' and
> Q, but cached queries only exist for a configurable TTL.
>
>> 2) the cache use is quite limited if the proxy also acts as authorizing
>> backend for the users, since binds are not proxied.  The proxycache
>> should be able to cache plaintext-like binds.
>> 3) if the proxy doesn't act as authorizing backend for the users, all
>> proxying occurs anonymously; this works around issue (1), but it still
>> makes the cache useless if the remote server requires binds, or protects
>> the proxied info with ACLs.  I have a solution for this by means of the
>> "idassert" feature of back-ldap, which required the cache to honor ACLs
>> (and thus the present commit). However, this solution suffers from issue
>> (2) when the proxy is also the authorizing backend for the users, since
>> it still requires at least a bind for all connections (in its current
>> implementation, it actually requires 2 (!) binds for each bind
>> operation, which is something I think I can easily fix and reduce to 1
>> for each connection, plus 1 at the first connection).
>>
>> p.
>>
>>
>>
>>     SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:
> +390382476497
>>
>
>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497