Re: [squid-users] transparent proxy with authentication

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@CATO.GD-AIS.COM>
To: squid-users@squid-cache.org
Subject: Re:[squid-users] 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
>
>
Received on Mon Oct 24 2005 - 21:44:31 MDT