[3052] in WWW Security List Archive
Re: Client->Proxy Authentification
daemon@ATHENA.MIT.EDU (David W. Morris)
Tue Sep 24 16:41:38 1996
Date: Tue, 24 Sep 1996 12:15:50 -0700 (PDT)
From: "David W. Morris" <dwm@shell.portal.com>
Reply-To: "David W. Morris" <dwm@shell.portal.com>
To: "Maria Jose Yanez Freire (Paco)" <myanez@ait.uvigo.es>
cc: www-security@ns2.rutgers.edu
In-Reply-To: <9609241334.AA14435@jucar.ait.uvigo.es>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 24 Sep 1996, Maria Jose Yanez Freire (Paco) wrote:
> I'm implementing a web proxy in an UNIX system and I need to know the uid
> of the client process who is connected to my proxy. HTTP authenfication
> mecanism is not a good solution because is designed to authentificate a user
> with a server, not a proxy.
> Another solution is the port 113 daemon defined in RFC 931 (used by NCSA
> 1.5 server) but many computers doesn't run this daemon.
>
> Is there any other solution?
HTTP/1.1 provides for proxy authentication ... depending on your time
frame and the clients you need to support and when they will have HTTP/1.1
conformant clients, that is a possiblity.
If your application server is tightly bound to its user community so that
cookie tricks won't raise their ire, you might be successful with a
combination of HTTP basic authentication and cookies.
Basically your proxy adds its own cookie to each response such that
the browser will always return the cookie. Your proxy also deletes the
cookie from each request so it doesn't cause problems at the origin
server. The trick is in the forcing of the cookie association with
all requests.
NOTE: This is an untried suggestion so prototype and
test it carefully with *EVERY* browser you expect to support (EVERY
includes brand, platform, and version).
The trick is to subvert HTTP authentication. As a proxy, look at each
request. If it includes your cookie, then you have you ID. If the
request includes your authenticate response, delete it. Delete your cookie
and forward the request.
If your cookie is not present, issue a WWW-authenticate challenge for
your domain as if you were simply a proxy for the challenge from the
origin. THIS IS IMPORTANT .... with your challenge include your cookie.
The response to the challenge will provide your userid. The cookie value
you provide must be a unique token which you can now associate in your
proxy with the userid each time you see a request. Delete the
authorization header and forward the request. If the origin server needs
to authenticate, it can do so as your cookie will stick and you don't
need your authentication data any longer.
This suggestion is not likely to be appreciated for an application which
is intended for access by a socially dispersed group of users. It is also
a hack which could get fragile in the face of very minor differences in
browser implementation or other proxy based applications between the
browser and your application.
Dave Morris
