> No, adding Basic is not an option because I will have to provide
> special "proxy passwords" to the users, or make them enter their
> Windows passwords by hand. This is highly undesirable. Once they
> logon into Windows, they must have (or not have) Web access
> transparently.
> 
> If you know how to achieve SSO with Basic auth, please share.
> 

I have a few idea's for out-of-band SSO, some of which I have experimented 
with...

1. agent running on AD server(s) looking at event logs for login events. I've 
done this from Linux using a wmi client but too much load.  The proposed agent 
would run on the windows server, collect IP<->username mappings, and squid 
would ask "which username is this IP address". Obviously there are shortcomings 
with this - it only works for domain joined devices, and assumes 1:1 
username:IP, which is not true on a multiuser device (terminal server)

2. as above but also an agent looking at Exchange logs (or imap or pop3 etc), 
which would allow authentication of mobile devices etc as long as they check 
their email via Exchange. This still has similar shortcomings to #1.

3. some bastardisation of identd. I've posted before about this. Identd assumes 
that the destination server is asking "who owns this connection" and so only 
gives port numbers because the IP is assumed from the ident connection (I have 
patched squid to fake the source address of the destination server so it works 
in transparent mode). Ident also has some serious security shortcomings, but 
they wouldn't be hard to solve. This new ident protocol would need:
  . to access the full details of the connection so a third party (eg squid) 
could ask who owns the connection)
  . to provide two-way authentication so that the endpoint would know that 
squid was authorised to ask about the connection, and so that squid would trust 
the endpoint to give a proper answer and not fake it
  . make a single connection between squid and the endpoint, rather than a new 
ident connection for every tcp connection which is a huge drain on resources.
This still has the drawback that it isn't going to work on mobile devices, 
requires an agent installed on each endpoint, and requires that squid knows 
enough details about the connection to be able to give the details to the 
endpoint (a router NAT-ing connections to squid would break this, you'd need to 
use WCCP), but it would solve the multiuser terminal problem.

Some combination of all three of the above would cover pretty much everything, 
and you could use a captive portal for whatever is left.

Apart from the ident fake-the-source-ip-address hack (works quite well!), and 
the wmi callout from Linux (works but too slow), the rest is just theory, but 
should be possible.

James

_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Reply via email to