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
Received on Mon Dec 13 2004 - 09:54:29 MST
This archive was generated by hypermail pre-2.1.9 : Sat Jan 01 2005 - 12:00:02 MST