Re: [SQU] Credentials forwarding?

Robert Collins wrote:

> > The implementation should kill flags.used_proxy_auth and instead look
> > for the peer option.
> I thought I had killed used_proxy_auth. Oh well.
> > WWW authentication can always be forwarded I think.
> Not true: Digest & NTLM & probably kerberos will fail to forward upstream
> properly. At this point _only_ basic auth can be used by a [reverse]proxy
> and a upstream proxy|server.

See the rest of this message.

> I think the configuration warning is needed. I can easily imagine a naive
> admin turning on upstream authentication and exposing all their OS passwords
> to their ISP :[

There is a note that should make most people grip that:

                                           Note: To combine this with
                     proxy_auth both proxies must share the same user
                     database as HTTP only allows for one proxy login.

But sure, we can add a more explicit warning if you thing that is
neccesary..

> If WWW authentication headers are forwarded always, we must never issue auth
> challenges to accelerated requests. Otherwise digest, ntlm & other protocols
> will fail (as I mentioned above). But sysadmins may want squid to handle the
> authentication, when the content is private, but not dynamic based on auth
> information.

As I said authentication in accelerators is an unofficiall thing not
really supported. There are too many alternatives on how one would like
to have it function in an accelerator, and it too easily collides with
transparent proxies which do look like accelerators to Squid.. So until
a couple wanting the feature in accelerators comes up with good
definitions of how they want things handled I opt to ignore the issue of
authentication in accelerators.

However, the same basic problems does apply to proxy authentication, and
is why a generic approach should be made to make Squid eat
authentication headers that belongs to it's own challenge/response
processing, and optionally add a custom connection header for passing on
the (decoded) user information to the next hop (parent proxy or
accelerated server, same thing actually).

Regarding acceleration.. I think the whole concept of how Squid is set
up for accelerators needs to be reworked. There are way to many pitfalls
and gotchas in the current way, and it collides to much with transparent
proxying.

An idea is to make use of cache_peer in accelerators. Add a
"origin/backend" class of peers, and a acl type to be able to match
accelerated requests only.

/Henrik
Received on Sun Dec 17 2000 - 22:07:40 MST