Re: [SQU] Credentials forwarding?

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Monday, December 18, 2000 1:12 AM
Subject: Re: [SQU] Credentials forwarding?

> Nope. But I did now an I do like the option but not the implementation.
Thanks.

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

This is due to where the challenge is created. Basic could fail if the realm
on the upstream server was different - different user domains may have
different passwords.

>
> So what I have done now is to take your patch and mangle it quite a bit.
> Instead of a new cache_peer option it now uses login=PASS, and WWW
> authentication is always forwarded. The fact that accelerators actually
> doing authentication might want want something else is ignored with only
> a code comment (accelerators with authentication not an officially
> supported thing, and requires reading code to enable in the first
> place..). The modified patch is in the sourceforge CVS under the tag
> "upstreamauth".

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 :[

I also think the WWW authentication needs to be resolved before this gets
committed. Also can you please make upstreamauth depend on auth_rewrite
rather than HEAD.

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.

Thoughts?

Thanks,
Rob

> /Henrik
>
>
> Robert Collins wrote:
> >
> > Ermm - has anyone had a chance to look over the patch I sent in creating
a
> > cache_peer option for forwarding authentication?
> >
> > Rob
> > ----- Original Message -----
> > From: "Henrik Nordstrom" <hno@hem.passagen.se>
> > To: "Chemolli Francesco (USI)" <ChemolliF@GruppoCredit.it>
> > Cc: "'squid users mailing list'" <squid-users@ircache.net>
> > Sent: Saturday, December 16, 2000 7:55 PM
> > Subject: Re: [SQU] Credentials forwarding?
> >
> > > Chemolli Francesco (USI) wrote:
> > > >
> > > > I've noticed that it's possible to supply a "login=user:pass"
> > > > option to the cache_peer configuration option.
> > > >
> > > > What I'd like to do is forwarding the credentials that the user
> > > > supplied, given that all caches have the same user database.
> > > >
> > > > Is it possible? If so, how? Thanks.
> > >
> > >
> > > Currently the proxy authentication forwarding mechanisms in Squid is
> > > utterly flawed.
> > >
> > > What should be done is that the current "forward unless used locally"
> > > mechanism should be ripped out, and instead a cache_peer option should
> > > be added. This also partly applies when doing www-authentication in
> > > accelerators.
> > >
> > > Search for PROXY_AUTH in http.c, and you will notice the flawed if
> > > statements I am talking about.
> > >
> > > --
> > > Henrik Nordstrom
> > > Squid hacker
> > >
> > > --
> > > To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
> > >
> > >
>
>
Received on Sun Dec 17 2000 - 21:11:56 MST