Hello,
On Jan 31, 2014, at 12:12 PM, Amos Jeffries wrote:
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.
I was looking for a way to make it easy for the end user to find
where they put their credentials.
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.
Would https help with this, or is it inherently insecure?
* 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.
What could be used as 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.
Okay.
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.
This is going to be a real problem. I need it to be unique to the
computer. Is there any work around for this?
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
Still, there is a lot that needs to be done to make this work. I
wonder if I would not be better off with some kind of thin client
that would just put the proxy settings into a computer for win/mac
and then give a place to put in a username and password. If this was
to reside in the tray or dock then it would make it easy to change.
Do you have, or know where I could get, a client for setting up the
proxy?
Thanks,
Al
