Re: [squid-users] authentication via web page

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
Received on Tue Feb 04 2014 - 19:55:59 MST