RE: domain attribute in digest auth

> -----Original Message-----
> From: Ronald.Tschalaer@psi.ch [mailto:Ronald.Tschalaer@psi.ch]
> Sent: Sunday, October 04, 1998 12:11 AM
> To: Paul Leach; HTTP-WG@hplb.hpl.hp.com
> Subject: 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.

> 
> > I don't know how to even configure any browser to do that.
> 
> 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.

> 
> > Even so, if need be, realm name space can
> > be allocated from the DNS name space and hence be globally unique.
> 
> True, but then you have to tell people to do so. Also, since the realm
> value is just about the only way a server can get some info 
> of sorts in
> the auth dialog box on browsers, it's used by a number of sites to to
> provde additional info (I'm not saying this a great idea...). These
> folks I believe would rather not have to litter the "message" with an
> extra DNS name just to guarantee uniqueness.

They only have to do it if they have wierd proxy server configurations with
proxies in multiple realms.

> 
> 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.

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.

Paul

Paul

Received on Tuesday, 6 October 1998 18:31:19 UTC