On 15/04/2015 4:25 a.m., HiP-HiPpO wrote: > Hello- > > I'm using squid version 3.5.3 and I could use some help with > configuration. First up, lets be clear: This is going to be difficult. The Apache setup you had appears to have been severely violating the HTTP *and* HTTPS protocols security requirements. You *will* have different behaviour from one endpoint or the other just by not using Apache. > > Squid will be installed at AWS, most clients will be within a corporate > network and will not be able to access the service by configuring proxy > settings in a browser. NOTE: That logic is false. Corporate networks / LAN are *the* use-case which is best suited to explicit browser configuration. You have AD policy, WPAD DHCP, WPAD DNS, user login scripts ror batch jobs, etc available to push out the settings. Other use-cases do not have some of those options, or they do not work as well as in a LAN environment. > Instead DNS will be used to resolve to the Squid > service. The Squid service will authenticate users via SLDAP. The > service will need to be able to intercept both clear and TLS HTTP traffic > in order to insert an Authorization header. At first reading this makes no sense. But what you go on to describe is in fact a reverse-proxy. SO.. forget the word "intercept", it has nothing to do with what you have set up. > > The request flow would be something like; > > Client browser requests http(s)://proxy-hostX.test.com > (where 0 < X < 50) > > Squid will need to intercept the request and add an Authorization header. Okay, ignoring the word "intercept", what you have here is just a proxy that performs login to some backend service(s). Fairly standard, though you have not said what authentication scheme the backend is using. That is an important detail. > Squid will need to rewrite the request to the origin server. In this > case, the origin server name is hostX.test.com > > Squid will then intercept the server response and direct that response to > an ICAP server to modify all embedded links to be the same as the > request. All links in the response will need to be rewritten to > http(s)://proxy-hostX.test.com This is where you start to have problems. Still ignoring the word "intercept", you have a proxy that uses ICAP adaptation to re-write both requests and response, mapping public URI resources to some essentially completely different private/intenral resoruce URIs. This ICAP part is very difficult, complex, and has nothing to do with Squid. So what it (ICAP) actually does to the traffic is not relevant here. In squid.conf you just need both a REQMOD and RESPMOD service configured. ICAP service does all the complex bits. NOTE: be aware that mapping between http:// and https:// scheme is expressly forbidden by both HTTP and HTTPS specifications. The security vulnerabilities introduced by doing so are extremely dangerous and have many unknowable side-effects. You need to be careful that ICAP service used does not cause it to happen. > > I have official wildcard certificates for the domain. i.e. *.test.com > > Squid will also need to retrieve group memberships from SLDAP and authorize > user access to hostX based on group memberships. If the user is in the > groups host30 and host43, then access is allowed to only host30.test.com > and host43.test.com The SLDAP part for finding group details and adding auth to the backend is pretty standard. Some limits apply, but pretty easy to do. BUT ... How do you determine which user made which request? The usual way is for clients to perform HTTP login to Squid. Anything else gets much harder, particularly for reverse-proxy. So, taking note of the fixed terminology I supplied above the wiki config examples should now be more useful to you: You have a reverse-proxy doing virtual hosting (<http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting>) also in HTTPS with wildcard certificate (<http://wiki.squid-cache.org/ConfigExamples/Reverse/SslWithWildcardCertifiate>) to multiple backend servers (<http://wiki.squid-cache.org/ConfigExamples/Reverse/MultipleWebservers>). You have ICAP services performing REQMOD and RESPMOD traffic adaptation: <wiki.squid-cache.org/Features/ICAP> You are performing some form of user identification, with group access controls (<http://wiki.squid-cache.org/ConfigExamples/Authenticate/Groups>), followed by authentication to the backend servers (<http://www.squid-cache.org/Doc/config/cache_peer/> see login= authentication options). HTH Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
