407/403 responses

Hi folk,
    Kinkie and I examining the behaviour of NTLM have found a significant
difference between what squid 2.4 has and what I implemented in
auth_rewrite.

The difference is in the behaviour for proxy_auth acl's when a user passes
the helper _authentication_, but fails the acl _authorisation_.

Sample acl's I'm referring to.
acl allusers proxy_auth REQUIRED
acl seniorstaff proxy_auth Mary

http_access allow seniorstaff
http_access deny allusers

I implemented the following logic:

A failed authentication resulted in a 407 (401 for accel mode).
A failed authorisation (ie John whose password is correct isn't in the list
of users for seniorstaff) results in a 403.

This occured for two reasons:
1) The NTLM code (and the digest code) _has_ to know about the user for the
beginning of the handshake - when it sends the NTLM challenge. Likewise for
the Digest code. Thus a failure on an acl once a user struct was associated
with the request is only indicative of the auth scheme sending a challenge.
We need to propogate the reason for the authentication failure back through
to the authentication code if we want to alter the behaviour based on
whether it's an authorisation or authentication issue. (And that can be done
via the auth_user struct I guess).
2) It made sense to me given that I was trying to limit the extent auth
changes needed reworking the information passed back through the code :].
Once the user is an authenticated user, authorisation controls don't have a
proper separate status code in HTTP. 403 includes in it's definition
"authorisation won't help".

So the question for the core team is:
Should I get the authentication code duplicating the 2.4 behaviour -
http_access deny line that fires on an authorisation failure (as opposed to
authentication failure) will generate a challenge from each and every
challenge?

Or is the new behaviour reasonable and thus should be left, but highlighted
in the documentation?

Rob
Received on Thu Jul 12 2001 - 04:09:41 MDT