Re: proxy authorization

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:28 PM 8/10/2003, Howard Chu wrote:
>Given that we have a proxyAuthz control now, which can cause particular
>operations on a session to be performed on behalf of another user, there's a
>bit of a gap in the feature set. Binds need to be proxiable too - given a
>scenario with a privileged user connected to slapd, performing ops on behalf
>of other users, we still need a way to verify the identify of a requestor.

Well, that task is left to the proxy.  The authentication mechanism
used by the proxy to verify the client identity may not even be
supported by the server, and even where it is, it may not make
any sense to "chain" the authentication as you suggest below.

Consider for example where TLS w/ client certificates and SASL/EXTERNAL
are used to identify the client but where the server has no TLS support.

Depending on the mechanism, what the proxy either needs access to authentication secrets (such as the DIGEST-MD5 A1 hash or userPassword)
or needs to have the server generate a SASL response suitable for the
proxy to send to the client (to ensure the proxy is not detected as
a man-in-the-middle).   Of course, for this to work, the proxy and
server must agree mappings between authentication identity to
authorization identities....

Now, if you were to limit this all to simple bind (which assumes
LDAP is used between the client and server), then I'd say that use
of an extended operation would be more appropriate than overloading
bind as the operation is not establishing an association between the
proxy and the server but used in the establishment of an association
between the client and proxy.  But, of course, one would likely have
this extended operation do most everything a bind operation can do
(including chaining).

Given this, I wouldn't go the extended operation nor the bind route.
Instead, I would code the proxy to use two LDAP sessions to the
server: One for authenticating its clients and one for accessing
information (either for itself or on behalf of its clients).

>Currently we do a Bind for this purpose, but that Bind has to be done over a
>separate connection because if it fails the connection will be left
>Anonymous, and if it succeeds the connection will be left as the Bound user.
>In a proxy server, we want the connection to be left as the privileged user
>regardless of Bind outcome.
>
>This seems like either the proxyAuthz control or perhaps the Noop control
>should be used. The Noop seems to best represent the desired functionality,
>while using the proxyAuthz control for this purpose seems cleaner from a
>conceptual level, i.e., proxyAuthz is used for all proxy-related
>operations...
>
>Thoughts?
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support