Special identities and connections in proxy backends

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

There might have been some confusion recently and not so far in the mind 
of at least one of the developers of the proxy backends (me).  
Especially back-ldap allows few slecial identities to be configured, 
which may serve some of the special purposes this backend is required to 
implement.

One of them is the "acl-bind" identity (see slapd-ldap(5)), which is 
used for operations that are privileged, meaning internal operations 
used by special internal features, or operations performed using the 
rootdn identity.  If this is enabled, and an operation occurs on a 
connection that's authenticated as the rootdn of the database (either 
because this is true, or because it is pretended by the code that called 
that operation of back-ldap), binding to the remote server occurs with 
the identity specified in the "acl-bind" statement, either using SASL or 
simple bind.

Another one is the "idassert-bind" identity.  This is used, if 
configured, whenever an authenticated connection tries to perform an 
operation thru back-ldap (this was recently added to back-meta as well) 
and that back-ldap database is not the authorizing database for the 
connection, and thus there is no other means to inform the remote server 
that the connection is authenticated.

Privileged connections get cached.  Connections used for idassert should 
be cached as well, as they always use the same identity, and typically 
assert that of the client by way of the proxyAuthz control.  The latter 
didn't quite happen until a recent fix, though.

The point is that there used to be (and there is, I haven't committed 
recent fixes yet, since I'm trying to convince myself that everything is 
now fixed :) some confusion about those special identities.  What I came 
out so far is that in the internal handling of those special connections:

1) privileged connections are treated some way
2) idassert connections are treated separately
3) in case a connection ought to be privileged, but acl-bind is not set 
and idassert-bind is set, the latter identity is used for privileged 
connections as well

I'm not 100% convinced about (3), though, because that would obfuscate 
what identity is used for what purpose.  The reason for (3) is that if 
one doesn't need to have privileged connections, he shouldn't set 
acl-bind at all; however, there might be cases where one wants to have 
identity assertion in place, and if acl-bind is not configured, 
connections as the rootdn wouldn't exploit it (this may happen, for 
example, when using slapo-chain(5) on top of a database that needs to 
have the rootdn in place).

So the point is: is it preferable to explicitly configure twice the same 
identity, or have a "sane" default if one only sets idassert-bind and 
not acl-bind?  All in all, the identity that's used for identity 
assertion is not likely to be more privileged than the privileged one...

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------