Note on ACLs: at present you may add whatever ACL rule you desire
to the Meta (and LDAP) backends. However, the meaning of an ACL
on a proxy may require some considerations. Two philosophies may
be considered:
a) the remote server dictates the permissions; the proxy simply
passes back what it gets from the remote server.
b) the remote server unveils "everything"; the proxy is
responsible for protecting data from unauthorized access.
Of course the latter sounds unreasonable, but it is not. It is
possible to imagine scenarios in which a remote host discloses
data that can be considered "public" inside an intranet, and a
proxy that connects it to the internet may impose additional
constraints. To this purpose, the proxy should be able to comply
with all the ACL matching criteria that the server supports.
This has been achieved with regard to all the criteria supported
by slapd except a special subtle case (please file an ITS if you
can find other exceptions: <http://www.openldap.org/its/>). The
rule
access to dn="<dn>" attrs=<attr>
by dnattr=<dnattr> read
by * none
cannot be matched iff the attribute that is being requested,
<attr>, is NOT <dnattr>, and the attribute that determines
membership, <dnattr>, has not been requested (e.g. in a search)
In fact this ACL is resolved by slapd using the portion of entry
it retrieved from the remote server without requiring any further
intervention of the backend, so, if the <dnattr> attribute has
not been fetched, the match cannot be assessed because the
attribute is not present, not because no value matches the
requirement!
Note on ACLs and attribute mapping: ACLs are applied to the
mapped attributes; for instance, if the attribute locally known
as "foo" is mapped to "bar" on a remote server, then local ACLs
apply to attribute "foo" and are totally unaware of its remote
name. The remote server will check permissions for "bar", and
the local server will possibly enforce additional restrictions to
"foo".
