On Mon, 13 Dec 2004, Romuald Guillou wrote:
The trouble is that a first client authenticate, through a pop up, with user name and password user1, he has privilege to surf internet. A second client, user2, want to go internet sites, bluecoat returns the authentication popup, the user click "cancel" then he can surf internet. In the logs we can see user2 has authenticated with user1 credencials. in this case squid is not passing the credentials of last user and not deny access.
I would say the authentication method used on your Bluecoat is busted and in reality gives the IP address of whoever is talking to your Bluecoat access.
This is quite understandable as HTTP does not have any cookies or similar which is directed to proxies, so if you are doing form based logins in proxies about the only key you have to identify the user session is the source IP address where the request came from. When using a proxy the source IP is the proxy address.
You could try to ask Bluecoat to include the X-Forwarded-For header in their session key to make their authentication a little bit more secure. This header is added by Squid and contains the original client IP address among other.. (may be more than one if there is a chain of Squid proxies involved)
If you want a reliable setup then I would recommend to use the standard HTTP authentication mechanisms; Basic or Digest HTTP Proxy authentication. Digest is more secure (not possible to sniff the password) but harder to integrate with user directories such as LDAP etc..
Regards Henrik
