[squid-users] Squid accel only after logon
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. http://wiki.squid-cache.org/ConfigExamples/Portal/Splash 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? Also is there a better way of achieving my purpose? Thanks. Please help.
Re: [squid-users] Squid accel only after logon
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
Re: [squid-users] Squid accel only after logon
Hi Amos,
Thanks a lot for your reply. It gave me clues on how to go about
finding a solution. I wasn't confused as such between proxy mode and
reverse proxy mode. Basically, I had access to squid and an apache
server to build an authentication mechanism to my target websites.
I used the splash page mechanism but wrote my own external acl type in
PHP. I used deny_info to present a PHP logon page which stored the
session info (user, last accessed etc.) in the database table and
stored a cookie on the client. I then configured squid to pass the
Cookie header (%>{Cookie:;PHPSESSID}) field to my external acl PHP
script which validated the session or modified or destroyed if not
valid any more.
It works great.
On 27 November 2013 11:19, Amos Jeffries wrote:
> 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
