Re: Authentication of both proxy and client

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

SASL provides a user authentication with proxy authorization
capabilities.  That is, a client can say "I am user X" or can
say "I am user X but I want to act like user Y".   The latter
can be used by a gateway application where.   In this case,
the client says "I am user FOO" to the gateway, the gateway
authenticates the user (possibly with assistance of the server),
then the gateway can access the server and say "I am the gateway
and I want to act like FOO".  The server needs to authenticate
the gateway and check its proxy policy (which says whether or
not gateway can act like FOO) [note that 2.0 does provide policy
support, that's HEAD only].

Note that the mechanism used by the client to the gateway
is independent to the mechanism used by the gateway to the server.
The client/gateway authentication could be TLS/EXTERNAL (or
whatever) and while the gateway/client could be DIGEST-MD5
(or whatever).

Note that also that I said the gateway can authenticate the
user with the assistance of the server.   This is somewhat
mechanism specific.  The gateway can play man-in-the-middle
(with weak mechanisms) or the gateway must authenticate the
client itself but may use information stored in the directory.
The latter (with simple password mechanisms) can be accomplished
today through use of an LDAP-enabled SASL features at the
gateway.

Kurt

At 02:13 AM 2001-10-22, Stig Venaas wrote:
>I would like users to access a resource by supplying username and
>password, and have the resource use LDAP for user authentication.
>I would like the resource to be authenticated first, and then I
>would like the resource to hand username/password to the LDAP
>server, thus delegating the user authentication to the LDAP server.
>
>If I understand SASL correctly, it won't do user authentication,
>only authorization. What I would like I think, is for the resource/
>proxy to use TLS with certificate authentication, and then have the
>resource bind on behalf of the user with the username/password the
>user supplied. This is possible to do today; the only thing I miss,
>is a way to refer to attributes and values in the client certificate
>in ACLs. That might be useful in other situations as well, or?
>
>Does this make any sense, or should I consider a completely diffe-
>rent solution? I suppose some would say that I should have the
>resource retrieve encrypted passwords (or other data) from the LDAP
>server, and validate the credentials on its own.
>
>Stig