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 <squid3@xxxxxxxxxxxxx> 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 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
