On 14.02.2012 04:15, Mr J Potter wrote:
Hi team,
I'm trying to set up an authenticating squid proxy with a nice login
box
rather than the one the browser pops up with a HTTP 407 request...
Does
anyone know how to do this? The main reasons for this are (1) to make
it
look nice (2) so that I don't have to tell people to put in
DOMAIN\user
into the box, (3) put some instructions as to what is going on and
(4) to
add a limited guest login option.
(1) is not supported by any of the web specifications at this point.
Someone in the IETF had a nice proposal to allow headers to be set from
<form> tag fields in HTML. I'm not sure where that went, at the time I
saw it was still looking for support to get to the Draft stage.
(2) is a feature of the AD or Samba PDC backend. They can be set to
require the DOMAIN part or add a default value if missing.
(3) permitting the server to determine what gets displayed on the login
area opens it to phishing vulnerabilities. For most of the auth schemes
the realm parameter is used by browsers after some heavy input
validation as part of the title or descriptive text of the login popup.
If you set it to a sane value the popup is self-explanatory to all
users.
This is where I am so far...
- I've got NTLM authentication working
- I've got a nice login page in ERR_CACHE_ACCESS_DENIED
and ERR_ACCESS_DENIED
- I've still got to write the bit to authenticate people, but I'm not
too
worried about that.
Highlights from my squid.conf file looks like this:
auth_param ntlm program /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 45
acl authdUsers proxy_auth REQUIRED
http_access deny !authdUsers ### Kicks up a 407 request
http_access deny all
The second last line is the tricky one - I can see why the line
http_access allow authdUsers
would trigger a 407 request, but I'd hoped the deny ! option would
get
around this.
Nope. Both lines REQUIRE auth challenge before they can be tested. The
deny line ending in an auth ACL also produces auth challenge when it
matches. The browser takes it from there.
The modern browsers all protect themselves against attackers by
discarding the response body (your page) on 407/403 status and using a
safe popup they own and can trust for secure user interaction.
What you can do instead of altering the form and popup is present a
session with splash page (your instructions) ahead of the login popup
like so:
external_acl_type session ...
acl doneSplash external session
# URI to display splash page with your instructions (no login form
allowed though)
acl splash url_regex ^http://example.com/Splash
# link ACL to splash page
deny_info 307:http://example.com/Splash?r=%s doneSplash
# let splash page go through no limits.
http_access allow splash
# bounce to splash page if not logged in yet AND this is a new session
http_access deny !authedUsers !doneSplash
# do login
http_access allow authedUsers
The page Splash gets passed the original URI in r=%s, which it can use
to present a "continue"/ "accept" link after reading.
Amos
