On 27/11/2013 8:58 p.m., P K wrote: > Hi, > > I want to use Squid as a reverse proxy (accel) to my main website but > only if they've authenticated - something like a captive portal (not > sure if that's the right phrase). By "authenticated", I don't mean > basic or digest etc. I want to provide my own logon page (say php) - I > can host another authentication website to host that. > > How do I go about achieving that? Splash page functionality is > something that looks promising in squid but I can't get my head around > how to force squid to reverse proxy my site only after users have > authenticated on my php splash page. Also I need to terminate their > session after 3 hours. > Okay. I think you misunderstand what a reverse proxy does and how it operates in relation to the main web server. A reverse proxy is simply a gateway to the main server which is used to offload serving of static files, do server-side caching, routing between different backends, certain types of access control and reduce impact from DoS attacks. It is better to simply pass all trafic through the proxy on its way to the main web server. The type of authentication you are describing is called application-layer authentication and exists outside of HTTP and thus outside of the normal capabilities of an HTTP reverse proxy. It can be done but with great complexity and difficulty. Once again it is better to leave the authentication non-authenticatino decisions to the main web server and have it send back appropriate HTTP headers to inform the proxy how to handle the different responses. > http://wiki.squid-cache.org/ConfigExamples/Portal/Splash > No your requirements do not match with the limits or capabilities of a captive portal. Captive portal uses an *implicit* session. Your system uses an *explicit* session. Please also note that captive portal *doe not* do authentication in any reiable way. The splash page can have application-layer authentication built in, BUT what the HTTP layer is doing is assuming / guessing that any request with a similar fingerprint as the authenticated one is authorized to access the resource. Being an assumption this authorization has a relatively high rate of failure and vulnerability to a large number of attacks. For example; the captive portal works mostly okay in situations where the portal device is itself allocating the IP address or has access to the clients MAC address information. Doing it on a reverse proxy will immediately have trouble from NAT, relay routers, and ISP-based proxies - all of which obfuscate the IP address details. > I can do something like this: > > #Show auth.php > external_acl_type splash_page ttl=60 concurrency=100 %SRC > /usr/local/sbin/squid/ext_session_acl -t 7200 -b > /var/lib/squid/session.db > > acl existing_users external splash_page > > http_access deny !existing_users > > # Deny page to display > deny_info 511:https://myauthserver/auth.php?url=%s existing_users > #end authphp > > #reverse proxy > > https_port 443 cert=/path/to/x_domain_com.pem > key=/path/to/x_domain_com.pem accel > > cache_peer 1.1.1.1 parent 443 0 no-query originserver ssl > sslflags=DONT_VERIFY_PEER name=x_domain_com > acl sites_server_x_domain_com dstdomain x.domain.com > cache_peer_access x_domain_com allow sites_server_x_domain_com > http_access allow sites_server_x_domain_com > # end reverse proxy > > > But how is this going to work? I can present a username/password on my > auth.php and present a submit button to validate. But how do I tell > squid that it is OK to serve x.domain.com? The external_acl_type helper is recording past visits and needs to determine its response based on whatever database records your login page did to record the login. > > Also is there a better way of achieving my purpose? Yes. Setup the proxy as a basic reverse proxy and leave the application-layer authentication decisions to the main web server. Application layer auth is usually done with session Cookies on the main server. You can check for Cookie header in the proxy and bounce with that same deny_info redirect if you like, to help reduce the main server load. It wont be perfect due to other uses of Cookie, but it will catch the definitely non-authenticated traffic. BUT you are operating over HTTPS. Why the avoidance of HTTP level authentication? Amos
