Re: [squid-users] authentication via web page

On 31/01/2014 11:56 a.m., Al Zick wrote:
> Hi,
>
> I am considering switching to authentication via a web page. Are there
> examples of how to do this somewhere? What are the pros and cons of this
> configuration? I am very concerned about security with web page
> authentication.

The Pro (singular) is that you can format the display to look any way
you like using HTML/CSS, images or other display technologies.

The Cons are many, but these are the major ones:

* HTTP and web auth are unrelated systems. There is no way for the
client software to know what HTTP credentials to deliver on followup
traffic.
 Web browsers and servers typically use a Cookie value exchanged back
and forth to store the credentials. This has a whole pile of security
issues in and of itself, on top of the other issues in this list.

* Web authentication is tied securely to the server endpoint which does
the authentication. The login does not cross to other domains. Thus any
Cookie or login may be required to be repeated many times while browsing.

The above cons essentially mean that web authentication for a proxy is
not possible with todays technology. We have to use a session workaround.
 * redirecting the client to a page which both authenticates and starts
a session for that client on successful authentication.
 * authorizing any request which matches the session. Making the
assumption that it is the same user/login. This is somewhat unreliable,
but can be used if the clients have a fairly static IP or a detectable
unique signature.

>
> Also, I am not really sure if it is a good idea. For example, in most
> emails the images in them are not sent as attachments, they are
> downloaded from a web server and go through the proxy. If a re-write was
> used to load the authentication page, then it would put that page in
> place of the image. How would you authenticate the proxy with this
> scenario?
>

The authentication will be linked to the URL redirected *to*. Not the
email embeded URL.

> I will probably need a consultant to help me through this project
> because I have been working on this way too long. Would anyone be
> available?

Maybe. If the session authorization scenario above sounds workable to
you take a look at the two session helpers bundled with Squid.

NOTE: that session by IP is for the *machine*. All software using it
shares the same session by IP address. If the IP is being NAT'ed for
multiple end-users they also all share the session.

1) the original squid_session / ext_session_acl helper acts in the same
was as a session for a browser when using a website. But for the machine
using the web proxy. The helper maintains its own BDB database of
sessions in the background.

 It has a passive mode (the default) where session are started
automatically on ever new IP address.

 It has an "active" mode. Where the session is not started until some
magic URL is requested. You create a login page that redirects to the
URL whereafter the session helper tells Squid an OK result. Then
redirect from there back to the original URL.

More details at:
http://www.squid-cache.org/Versions/v3/3.3/manuals/ext_session_acl.html
http://www.squid-cache.org/Versions/v3/3.4/manuals/ext_session_acl.html

2) the newer ext_sql_session_acl helper bundled with Squid-3.4+ acts in
a slightly different way. It performs a SQL database lookup for a string
matching whatever fields you put in the external_acl_type format.
Returning OK/ERR results to Squid along with a username / label for an
existing session that matches.

 With this one you redirect to your authentication page like usual. But
instead of redirecting to a magic URL on success the auth script needs
to update the SQL database and redirect back to the original URL.

More details at:
http://www.squid-cache.org/Versions/v3/3.4/manuals/ext_sql_session_acl.html

Amos
Received on Fri Jan 31 2014 - 17:13:11 MST