Re: /bzr/squid3/trunk/ r9933: Fully transparent PASSTHRU option for authentication to peers.

ons 2009-08-26 klockan 02:32 +1200 skrev Amos Jeffries:

> I kind of agree. This is a step towards cleaning up the permutations a
> bit. The old ones are not really pass-thru. As you note they all did
> some synthesizing which can under some circumstances is mutually
> exclusive with real pass-thru.

They only syntesise if there is nothing to pass-thru.

> The fact that the first two were abusable as pass-thru and PASS in
> particular in too many guides used as semantic transparent pass-thru is
> a problem.

How so?

> > PASS -> WWW+Proxy authentication passed along as-is if present.
> > external_acl auth added as basic Proxy-Auth if none present.
>
> Ideally yes. However the addition of Proxy-Auth from local environment
> (without the option NOT to) breaks setups where side-band auth is done
> and the real header auth needs to be fully semantically transparent.

In such use case one does not sideband inject full credentials, just the
username.

> I'd like to see PASS die simply because of the confusion we see in the
> help lists. PASSTHRU is intended to replace it for most peoples intended
> usages.

What is the problem with PASS synthesising a Proxy-Authenticate header
when both of the following is true:

 a) There was not Proxy-Authenticate header present in the request
 b) Complete credentials was provided to Squid via sideband
(external_acl), that is both login & password. The only thing the
password is ever used for is synthesising this header.

> PROXYPASS not being documented to date has been a stroke of luck. It's
> behaviour can be modified only slightly and without affecting any
> correct configurations which already should have originserver and
> login=PROXYPASS

PROXYPASS is really a cornercase. Normally should not be used.

> Which would bring it back to two officially supported for 3.2:
>
> PROXYPASS synthetic WWW-Auth if originserver
> PROXYPASS synthetic Proxy-Auth if not originserver
> PASSTHRU semantic transparency
>
> ... and we deprecate login=PASS as replaced.

I do not share this view.

PROXYPASS is dangerous and it's use should be very very carefully
considered. It's actual use-case is to provide a kind of single-sign-on
to a environment where Squid is acting as both a proxy and reverse-proxy
for servers in the same administrative domain, giving users within that
network single-sign-on to all the servers by the fact of being
authenticated to the proxy.

It's very likely the external_acl provided credentials haven't been
fully tested in originserver cases (independent of PASS/PROXYPASS). It's
use case when added was proxies doing auth based on src ip and needing
to forward auth to upstream proxy.

> This is what is _now_ happening when PROXYPASS is specified: Proxy-Auth
> is only passed in its WWW-Auth form if that translate is hit.

Ok.

> Before this addition PROXYPASS was semantic transparent for Proxy-Auth
> and as you describe for WWW-Auth. Depending entirely on the
> 'originserver' flag.

Running a test here with Squid-2 to compare.. and results for
synthesized login is a bit strange for originserver peers... not what is
intended..

Regards
Henrik
Received on Wed Aug 26 2009 - 07:23:21 MDT