Re: domain attribute in digest auth

> > > I don't know of any scenario where I'd want to point my browser
> > > at multiple proxies that aren't in the same protection domain.
> > 
> > How about if authenticated proxies are used to allow and limit
> > access to intranets from the outside? Or if a corporation wants to
> > split their intranet into divisions or BUs and provide access to
> > outsiders via authenticated proxies? I have no idea if anybody is
> > doing  this or wants to do this, but then again I keep keep getting
> > surprised at what kinds of applications and setups are being built.
> > If all proxies are put in the same protection space then you're
> > cutting off these sorts of possibilities. By making proxy auth work
> > similar to server  auth you are leaving the possibility open.
> 
> First, I don't understand the scenarios: you haven't explained why the
> proxies are in different protection domains.
> 
> Being in the same protection domain just means that the browser will send an
> Authorization header. If the credentials supplied in that Auth header fail,
> then the proxy will return a 401, and different credentials can be supplied.

Yes, but then each time you go to a different proxy you will be prompted
for your username and password again. There are applications and setups
out there (I'm not making this up, btw) which use multiple proxies and are
configured with a list of proxies and a list of URIs for each proxy (i.e.
which proxy to use for which URI). Now, if these proxies require
authentication then that means that the application has to keep changing
the (single) stored username/password before it access the URI. This also
incurs unnecessary 407's, of course.

Or back to the above example: you split the company net up along BUs (or
whatever they call them), providing access to a given BU's net via a
proxy (which needs authentication), and configure the browsers to use the
appropriate proxy for all the URIs on each BU's net. Furthermore, each
proxy requires a different username/password because you want to be able
to give users access only to a select few BU's info. Now, if a user
(which has access to multiple BU's info) browses one BU's stuff (thereby
using that BU's proxy and entering the necessary username/password), then
browses a second BU's stuff (again entering the corresponding credentials
for that BU's proxy), and then goes back to the first BU she will have to
enter the credentials she already entered earlier just because we are not
allowing different proxies to be in different protection spaces and
therefore not letting the browser store more than one set of credentials.

Basically, proxies can not only be used to get out of an firewalled net
(among other things), but also to get into one (in a controlled manner).
Therefore a client may need to use different proxies for different URIs,
and since access permission for one proxy does not imply access permission
for another it may need to supply different credentials for these proxies.

> > Netscape at least allows for script based setting of proxies and if my
> > memory serves me right you can set different proxies for different
> > URLs. Don't know if it handles multiple proxy-auth correctly, though.
> 
> So does IE. It downloads the script from a "base proxy". I've only ever
> seen the scripting capability used to implement a proxy farm.

Heck, I've never used it at all but that doesn't mean others don't use
it for all sorts of stuff.

> > The question though is why go through all this? What are you trying to
> > gain by ignoring the domain attribute? It doesn't simplfy the client
> > any (since you can use basically the same code for both server and
> > proxy auth), nor do I see it simplyfying the proxy much, nor does it
> > simplify the spec (you'd need to add words about the necessity of
> > making the realm globally unique).
> 
> Its way late to be making changes unless there's a compelling reason. It was
> not obvious what domain= would be good for with Proxy-Auth, so I said that
> it should be ignored. The current spec at least is nicely interoperable. I
> don't need to say anything about making the realm unique. I could say the
> Proxy-Auth should ignore realm, if you wish.

Making all proxies belong to the same protection space is changing the
spec! If you leave the spec as it is now then Proxy-Auth is subject by
the same protection space definition as server auth ((host port realm) tuple)
but you have no way to extend that space over multiple proxies. I believe
changing the domain attribute wording as suggested is A) less of a change
than redefining the protection space of proxies, and B) more useful.

> The requirements here are unclear (to me at least). The most I want to do
> at this point is to make sure that we don't get in the way of adding
> extensions. I'd be happy to say that domain= is ILLEGAL for Proxy-Auth.
> Then if we figure out what its good for and what its semantics are, we
> can write an RFC for an extension to Digest.

I don't see why the semantics should be any different from those for
server auth - the (host port realm) tuple defines the protection space,
with the domain attribute as a means for extending that to a
(list-of-hosts list-of-ports realm) (the host and port here just refer
to the proxy's host/port instead of the server's host/port, that's all).


  Cheers,

  Ronald

Received on Thursday, 8 October 1998 00:00:48 UTC