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? For the other problem about authentication being asked twice - No the target server does not need any basic authentication. 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. On 22 November 2013 11:53, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 22/11/2013 11:16 p.m., P K wrote: >> Hi, >> >> I can't get the reverse proxy to work properly. Basically I want squid >> to serve as reverse proxy to two of my domains - x.example.com and >> y.example.com. I also want squid to perform basic authentication >> against my own radius server which should be common for both the >> sites. I mean I want users to authenticate once and it should work for >> both x.example.com and y.example.com. Here's my config: >> >> >> auth_param basic program /path/to/basic_radius_auth -f >> /path/to/squid_rad_auth.conf >> auth_param basic children 5 >> auth_param basic realm PRIVATE >> auth_param basic credentialsttl 4 hours >> auth_param basic casesensitive on >> >> >> https_port 443 cert=/path/to/x_domain_com.pem >> key=/path/to/x_domain_com.pem accel >> >> cache_peer 1.1.1.X parent 443 0 no-query originserver ssl >> sslflags=DONT_VERIFY_PEER name=x_domain_com >> cache_peer 1.1.1.Y parent 443 0 no-query originserver ssl >> sslflags=DONT_VERIFY_PEER name=y_domain_com >> >> acl sites_server_x_domain_com dstdomain x.domain.com >> acl sites_server_y_domain_com dstdomain y.domain.com >> acl radius-auth proxy_auth REQUIRED >> >> >> cache_peer_access x_domain_com allow sites_server_x_domain_com >> cache_peer_access y_domain_com allow sites_server_y_domain_com >> cache_peer_access x_domain_com deny all >> cache_peer_access y_domain_com deny all >> >> >> http_access allow radius-auth >> http_access allow sites_server_x_domain_com >> http_access allow sites_server_y_domain_com >> >> >> ...<snip> ... >> >> >> >> With this config: >> >> 1. I launch https://x.domain.com on a browser. It prompts for >> user/pass. I enter it and then it prompts again. I enter it and then >> it lets me in. Not sure why this is happening. Is it because the >> target site has IPTables NAT from 443 to 6443? If so how can I get >> around that? > > Does the web server require the auth credentials as well? > If so try adding login=PASSTHRU to the cache_peer lines. That will > send the users credentials to it. Otherwise login= can be used with an > explicit login user:passwd to be sent to the peer server. > > >> >> 2. I launch https://x.domain.com and authenticate. It lets me in. Now >> I change the URL on the same browser to https://y.domain.com. It asks >> for authentication again. Why? How can I get around this? > > Why. Because they are different domains. And no there is no way to get > around that. It is a requirement of web security that login credentials > are scoped by domain and are not permitted to be delivered to any other. > > There is no reason to expect any two differently named domains use the > same authentication backend even if they are contacted through the same > proxy or even hosted on the same IP:port. > > PS. we already have requests from people wanting different backends on a > *path prefix*. Yuck. > >> >> PS: I know it is not possible to virtual host SSL and I need a wild >> card cert. But I don;t care if I get a certificate warning with >> y.domain.com. > > The latest Squid versions have SSL capability of generating > certificates. You may want to try using that > It has become possible in the lastest Squid versions with the > infrastructure added to generate certificates. > >> >> Please could someone have a look and tell me what I'm doing wrong? > > > Firfox and Chrome are getting rather pedantic about some of those errors > nowdays. To the point where user override is no longer possible on > certain warnings. They just refuse to connect to the server. > > Amos
