Re: passing on Proxy Authentication

> From: "Nottingham, Mark (Australia)" <mark_nottingham@exchange.au.ml.com>
> Resent-From: http-wg@hplb.hpl.hp.com
> Date: Mon, 14 Sep 1998 09:56:44 +1000
> To: "'Paul Leach'" <paulle@microsoft.com>, http-wg@hplb.hpl.hp.com
> Subject: RE: passing on Proxy Authentication
> -----
> 1. figured that, just an idea
> 2. to provide users with a single login (both in details and in instance;
> i.e., they do it once, not once for each server) for all company-related Web
> services (including proxies), without resorting to proprietary
> authentication methods. On a complex network with many disparate Web
> services, this can be an easy way to tie authentication together.
> 3. It isn't; if a user goes to a protected Web service, they'll still get a
> WWW-Autheticate header in the response. This means that they'll have to
> authenticate themselves separately on each server, as well as override their
> proxy settings, which should be enough encouragement to go through the
> proxy.
> 
> Perhaps an example is in order. Imagine a network with a proxy called
> 'proxy' and Web servers called 'foo', 'bar' and 'baz'. A user fires up their
> Web browser, which will go to a proxy (for our example, let's assume that
> it's a big network, and that even local traffic goes through a proxy). After
> authenticating themselves on the proxy, their requests to it will include a
> Proxy-Authorization header. What I'm suggesting is that the proxy could be
> configured to translate that into a Authorization header and pass it on to
> selected Web servers (foo, bar, and baz, perhaps *.foo.com, but never
> anything else), so that the user does not need to re-authenticate
> themselves.
> 
> 

The revised digest authentication can be implemented to allow cross server 
sharing of authentication information (without the danger of stealing 
of one header allowing access to other servers), which should solve this 
problem (without the kluding of using a proxy to do the translations).

The back end servers can communicate among themselves the authentication
information with whatever protocol is appropriate (e.g. Kerberos).

This was one of the major flaws in RFC2069, and is being fixed in
the revision.  Paul Leach had the idea that makes this feasible
after 2069 was issued.

Please look at a current draft of the revision to see the details.

				- Jim

Received on Monday, 14 September 1998 06:37:35 UTC