Re: [squid-users] Reverse Proxy multiple sites with basic auth

I appreciate your help Amos. Please bear with me.

I can solve the basic auth problem by bringing https://x.domain.com
and https://y.domain.com into one roof i.e.
https://common.domain.com/x and https://common.domain.com/y. But
that's much bigger piece of work for our organization. So I'm trying
to avoid that.

> Answer this then: How is the browser to know they are the same when the
> domain name presented tells it that a *different server* is being contacted?
>
> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p7-auth.html#rfc.section.6.2
>
> The browser will not broadcast your users credentials to every website
> they connect. They will instead send one request without credentials on
> first contact to a domain and only send what it believes to be the
> correct credentials after the challenge comes back telling it what
> domain+realm needs login.

The browser does not need to know. It is the squid that asks the
browser to supply authentication creds first right? I'm thinking
something like this:

1. Browser requests https://x.domain.com
2. Squid checks if this browser has authenticated on y.domain.com or
x.domain.com in the past 4 hours. If no then send 401 not authorized
asking for credentials for x.domain.com.Browser will keep sending
credentials in the Authorization header from now on and squid caches
the auth creds.
3. Browser requests https://y.domain.com. Squid already has creds for
x.domain.com cached. So it lets the browser in.
4. 4 hours have passed. Creds expired. Browser requests
https://x.domain.com. Squid sends the challenge again.

Is this possible with external acls or something? I may be talking
complete nonsense here. So please bear with me.

Thanks for your help.

On 23 November 2013 05:27, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 23/11/2013 12:57 p.m., P K wrote:
>> Thanks Amos.
>>
>> That causes a big problem for me if basic authentication cannot be
>> shared across domains. Is there anyway I can configure squid so that
>> authentication challenge is sent for one or the other but not both.
>> For e.g if user is authenticated (basic) on siteA then don't ask for
>> authentication on siteB. Is this possible with squid in my
>> configuration?
>
>
> Answer this then: How is the browser to know they are the same when the
> domain name presented tells it that a *different server* is being contacted?
>
> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p7-auth.html#rfc.section.6.2
>
> The browser will not broadcast your users credentials to every website
> they connect. They will instead send one request without credentials on
> first contact to a domain and only send what it believes to be the
> correct credentials after the challenge comes back telling it what
> domain+realm needs login.
>
>
>>
>> For the other problem about authentication being asked twice - No the
>> target server does not need any basic authentication.
>
> Then WTF are you bothering with it? see below.
>
>> It is running
>> tomcat. Squid causes browser to prompt for authentication when I type
>> https://x.domain.com. Then the url changes to include
>> /something;jsession=...... and then I get prompted again.
>>
>
>
> !! your users have logged into no less than three different security
> systems by the time that paragraph description is over:
> * HTTP authentication
> * TLS
> * Java Cookie session
>
> THE PROBLEM you have is all that bouncing is crossing between different
> zones of secuity. If you have to bounce people around at all, do it
> without requiring authentication on the point of first contact and only
> on the final service itself.
>
> For example:
> 1) http://x.domain.com bounces without auth to https://x.domain.com
> 2) http://y.domain.com bounces without auth to https://x.domain.com
>
> 3) https://x.domain.com does the type of auth the server requires and
> keeps the user there in its protection while their browsing session happens.
>
>
> Squid can even do the (1) and (2) redirects for you to save load on the
> origin server.
>
> Also, please read this
> https://randomcoder.org/articles/jsessionid-considered-harmful
>
> Amos
Received on Sat Nov 23 2013 - 11:51:26 MST