[Date Prev][Date Next] [Chronological] [Thread] [Top]

proxyAuthz propagation in back-ldap

I'm concerned about using the "binddn" identity
for proxy authz propagation using back-ldap.
The "binddn" (although the name now appears a bit
obscure and mileaing) is essentilly intended to
bypass ACLs on the remote server for proxy internal
ops.  I'm considering the possibility of using
different identity for prozy authz.  This because
the presence of its dedicated administrative dn
would be used to enable the feature, and this
should be clearly separated from the need to define
the "binddn"; moreover, I expect that such user
should have very specific privileges, generally
different from those of the binddn:

    - auth permission
    - essentially read access to *

    - auth permission
    - read access to its own entry's saslAuthzTo
      attribute, or
    - read access to others' saslAuthzFrom attribute,
      for fine grain authz policy



Pierangelo Masarati