Re: authentication cleanups

Tony Sanders (sanders@bsdi.com)
Thu, 10 Nov 1994 06:13:48 +0100

Brian Behlendorf writes:
> This makes great sense. Right now browsers (we're hoping!) resend names
> and passwords for every access to the same machine and port. Obviously
> for some other situations this is less than ideal. I'd also like to see
If you check the access logs on www.wired.com you'll note that I wrote
my letter to www-talk about 10 minutes after signing up :-)

Yes, that means I only thought about this for about 10 minutes before
spouting off but it seemed pretty obvious that what was needed was some
way to tell the client what was going on and since URLs are supposed
to be hierarchical I figured this was a done deal, just tell them.

Another feature is that this doesn't impact existing clients at all,
it's just hints to help make things a little bit smarter. Totally
optional on both ends.

> the ability to put other machines and ports in the WWW-Realm-Partial line
> WWW-Realm: /, kino.hotwired.com, staffweb.hotwired.com:8000/Staff/
Yes I agree, however, it should be an arbirary URI, so let's
call it WWW-Realm-URI:

> I don't see any security problems with declaring another host as a member
> WWW-Realm: /, www.nsa.gov
As Dan pointed out, you are telling hackers about other systems and paths
on your server which some people might not want to do; but as a famous
doctor once said, "don't do that" :-)

Seriously though, there is no reason you couldn't just send WWW-Realm-URI
after the user was authenticated. If you do that then you aren't giving
away anything because the server can know what the user is allowed to
know. Also, as shown below, a partial of the directory already accessed
could be returned if that is prefered (or nothing, it's totally up to the
server).

Client:
GET /protected/recipies/secret-sauce/ingredients HTML/1.0
Server:
401 Unauthorized
WWW-Authenticate: Basic realm="burgers_and_fries"
WWW-Realm-URI: /protected/recipies/
Client:
GET /protected/recipies/secret-sauce/ingredients HTML/1.0
Authorization: Basic mickeyd:passwd
Server:
200 Ok
WWW-Realm-URI: /protected/recipies/, /protected/foodstuff/
WWW-Realm-URI: http://otherserver/protected/foods/

> A given user comes here, enters a name and password, and follows a link to
> www.nsa.gov. The client enters the cached name and password there, which
> fails. They then enter a name and password that succeeds. If they come
> back to my machine, the client should *not* send the cached name and
> password from www.nsa.gov, even if www.nsa.gov didn't specify a realm -
> if it did so, I could get that user's valid name and password to
> www.nsa.gov if I wished, which would be bad.
Of course, just because you trust them doesn't mean they trust you.
This should be in the spec so that it is clear, assuming some
scheme like this is adopted.

Also, clients shouldn't trust other servers that use the same realm names
[obvious yes, but it should probably be in the spec anyway]