[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Access control in pcache
Pierangelo,
Query results can be merged into the cached content even if an identical
query for a different client is cached earlier. Merging will involve adding
any new entries or attributes and overwriting common attribute values from
common entries. This is similar to the way queries with overlapping result
sets are handled now.
However, to ensure ACL enforcement for answerable queries, the following
need to be ensured: (i) only entries returned for the containing query
should be searched, (ii) only attributes returned for the containing query
should be returned (if requested). Containment above refers to both the
query and identity containment checks.
I was thinking of ensuring (ii) by storing some meta information about
returned attributes at query level. However this will not work if access
control is not specified in terms of filters, in which case, ensuring (i)
and (ii) require entry level meta data to be maintained. Currently a
queryid attribute is being used to ensure (i). One way to ensure (ii) is to
have an attribute (say entryACI/OpenLDAPaci) in every cached entry which
is used to store access control information. A bind DN should be granted
access to only those attributes and entries which were returned for a
cached query requested by the bind DN.
This looks like one possible way of handling ACL enforcement at the cache
without knowledge of ACLs at the backend server. Please let me know your
thoughts.
Regards,
Apurva
-------
owner-openldap-devel@OpenLDAP.org wrote on 11/19/2004 03:02:34 PM:
> 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
>