W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2003

RE: Chained proxies, persistent connections, authentication

From: Rob Maidment <rob.maidment@clearswift.com>
Date: Fri, 24 Oct 2003 11:10:31 +0100
Message-ID: <2F9121839AC40648B42FBC550E932A71673A35@is~farnsworth.europe.clearswift.com>
To: ietf-http-wg@w3.org


Thankyou for all the contributions on this thread.  

I over-simplified the proxy1 (Squid) role in the scenario slightly for the
sake of clarity, so I'll explain exactly what is going on:  Squid is
authenticating the users, using the Basic authentication scheme I assume.
It then consollidates these users into 5 roles-based groups.  When Squid is
asked to authenticate with the upstream proxy (proxy2), it responds with one
of 5 user IDs, to indicate which group the user falls into.  Proxy2 then
applies a security policy based on the group.  So proxy1 is not literally
passing through the end-user authentication; it is responding to upstream
authentication differently depending on which user is making the request.

The problem occurs because proxy1 re-uses persistent connections to proxy2
for users in different groups, and proxy2 only authenticates the first
request on each connection.  So subsequent requests may have the wrong
security policy applied.

Thanks to your responses, I now realise proxy2 is at fault since it is
individual requests that should be authenticated, not connections.  I've
also learnt there may be a workaround by disabling server-side persistent
connections in Squid.

As a matter of interest, if the roles were reversed would Squid authenticate
every request, or only the first request on each connection?  

Thanks again,
Rob.



---------------------------------------------------------------------------------------------------------------
Clearswift monitors, controls and protects all its messaging traffic in 
compliance with its corporate email policy using Clearswift products. 
Find out more about Clearswift, its solutions and services at 
www.clearswift.com.
***********************************************************************************
This communication is confidential and may contain privileged 
information intended solely for the named addressee(s). It may not 
be used or disclosed except for the purpose for which it has been 
sent. If you are not the intended recipient, you must not copy, 
distribute or take any action in reliance on it. Unless expressly stated, 
opinions in this message are those of the individual sender and not of 
Clearswift. If you have received this communication in error, please 
notify Clearswift by emailing support@clearswift.com quoting the 
sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain.
This footnote confirms that this email message has been swept by 
MIMEsweeper for Content Security threats, including computer viruses.
Received on Friday, 24 October 2003 06:10:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:25 GMT