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
