Thanks Merton for explaning.
What if the design is changed from wccp to a redirection level7 switch
such as foundry serveriron? L7 switch redirect http traffic to squids.
Will this be able to design provide authentication from squid?
If transparent squid cant provide authentication due to the
complications, would you recommend we get all users to enter proxy IP at
their own browser before they can browse, so that authentication can
still be provided? If there is a proxy pool (a few proxies for
redundancy), then I may use a L7 content switch to provide a virtual
proxy IP for all user browser to point to, then the content switch will
route the user to the least loaded squid. All squid will definitely be
now be authenticating users against the Sun Ldap server.
I understand that servers may be affected by this. However, I could set
at firewall that only IP at Server Farm can have http direct to
internet, bypassing proxies.
To prevent users from going directly to Internet, firewall will block
their IP from http access direct to internet.
The objective of this is to enable logging of login with url accesses on
shared computers. Such computers are like those in computer labs where
anyone can use to access to internet. If you do have alternative control
mechanism, please advise.
Thanks again.
Kah Yi
-------- Original Message --------
From: Merton Campbell Crockett <mcc@xxxxxxxxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxx
Subject: Re: transparent proxy with authentication
Date: 25/10/2005 10:47
On Monday 24 October 2005 18:36, Chin Kah Yi wrote:
Dearest squid expert out there,
Don't mind me being asking again - but why was authentication designed
not to work with wccp? If transparent proxy design is required together
with authentication, is there any alternative I could work on?
With WCCP you are intercepting the HTTP request from the HTTP client. The
HTTP client assumes that it is communicating with the HTTP server. If the
HTTP intercept proxy were to request authentication, you would have one of
the following problems.
(1) The HTTP client would present the credentials that it saved from
the last time that it accessed the HTTP server to the HTTP intercept
proxy. These credentials would fail the authentication tests and
access would be denied.
(2) If the HTTP client did not have any credentials saved, the user would
present the credentials requested by the HTTP intercept proxy. The HTTP
client would save the authenticated credentials. If the HTTP server does
not require authentication, there is no problem.
(3) If the HTTP server requires authentication, the HTTP client would
present the credentials required by the HTTP intercept proxy. The
authentication would fail and the HTTP client would be prompted to
provide new credentials.
Obviously, this leads to a condition where the HTTP client needs to supply
multiple credentials on every access. It is important to note that not all
HTTP clients are browsers (Firefox, Internet Explorer, Netscape, Safari,
etc.). Many are applications or services such as AIM, Jabber, Real Audio,
etc.
It might be possible to implement authentication in an HTTP intercept proxy
were realms consistently used and understood by all HTTP clients and servers.
However, the last time that I looked at this problem (ca. 1999), I discovered
that while HTTP clients tended to deal with realms correctly there was a wide
variance in the way realms were implemented in HTTP servers with Microsoft
IIS being the biggest problem.
Merton Campbell Crockett
