OK, so here's another pseudo code that comes to my mind, this is somehow similar to some commercial products (Ironport, bluecoat):
- The user connects to http://www.somesite.com via the proxy - The Proxy redirects to http://authenticationportal/http://www.somesite.com with 302 return code. - User is verified/authenticated on the authentication portal. This authentication portal sets a cookie and redirects to http://www.somesite.com - User connects to http://www.somesite.com via proxy. Proxy knows user is authenticated (cookie). The problem is with the last step since the cookie is bound to http://authenticationportal so the user may encounter an endless loop. Do you know the solution for letting this authenticated user go to the target after being authenticated 2012/4/3 Amos Jeffries <[email protected]> > > On 3/04/2012 3:40 a.m., Mohamed Amine Kadimi wrote: >> >> Dear Developpers and Community, >> >> I would like to set up the following configuration using squid: >> >> When a user asks for a web page he is transparently redirected to >> squid, where an authentication must be done before serving the user >> with content. > > > Please read > http://wiki.squid-cache.org/SquidFaq/InterceptionProxy#Why_can.27t_I_use_authentication_together_with_interception_proxying.3F > > > >> >> However, users IP are being NATed before going to the proxy. So the >> solution would be to use an application-layer verification: cookies or >> http headers >> >> So, I come across the following solutions: >> >> 1. Use an ICAP server which checks if a cookie is set, otherwise set >> it for an authenticated user >> the problem is: cookies are bound to domains + each http request must >> be validated >> >> 2. Use a php splash page which sets the cookie then redirect to destination >> same problem as ICAP >> >> 3. using squid authentication and checking if Proxy-Authorization >> header is set before serving the client >> problem: sessions are associated to the IP by squid >> >> I'm using squid 3.1 >> >> Thank you for any idea > > > The whole point of transparent interception is that the browser is > *completely unaware it is talking to a proxy*. It contacted some web server, > and *all* of its communications are with that server. If you can find a way > to trick it into storing security credentials of any kind set by your proxy > it will consider those credentials safe to use when contacting the same > server via other non-HTTP methods as well, causing great deal of problems. > The good thing to do at that point is to report the zero-day security > vulnerability you just found. > > > You might be able to use details gleaned from the browsers request to *guess* > what user it is and have a external_acl_type script inform Squid of the > guessed username. Or the authorize (*not* authenticate) the request to happen. > > Amos -- Mohamed Amine Kadimi Tél : +212 (0) 675 72 36 45
