Search squid archive

Re: enabling X-Authenticated-user

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/03/2012, at 1:45 PM, Brett Lymn wrote:

> On Thu, Mar 01, 2012 at 03:07:42PM +1300, Amos Jeffries wrote:
>> On 01.03.2012 14:32, Brett Lymn wrote:
>>> I have an application that pays attention to the X-Authenticated-User
>>> header.
>> 
>> Why? what does it do?
>> 
> 
> Apparently, it believes it.  I don't _think_ it actually does any
> further authentications based on the information from what I can see but
> just uses the username presented for its own internal machinations.
> 
>>> I need to use this application as an upstream proxy and need to
>>> have the user authentication passed from squid through to this
>>> application.
>> 
>> What happens to the user if Squid accepts the credentials and 
>> authenticates them. But the other proxy does not? important.
>> 
> 
> Given that both are querying the same auth database (windows AD) this is
> unlikely in our situation.
> 
>>> I know about the login=PASS cache_peer directive but I am
>>> wondering how that plays with negotiated authentication schemes like
>>> kerberos.
>> 
>> 
>> In HTTP proxy-auth credentials are decided at each and every hop down 
>> the chain servers. login= is the way Squid uses to determine what 
>> credentials are valid for the next peer. The same directive can also 
>> completely replace the downstream credentials, wholly or partially and 
>> send a new set upstream.
>> Kerberos connection-based nature forces this fact right up into your 
>> face. Needing a new keytab token at every proxy. Squid 3.2+ supports 
>> login=NEGOTIATE to send your Squid's Kerberos credentials to the next 
>> proxy down the chain.
>> 
> 
> Hmmm I don't think that is what I need - I really need to pass the name
> of the user that made the connection to squid upstream.  I have just
> tested login=PASS and that works fine for basic auth but kerberos fails.
> 
> 
>> Login from user to web servers is irrelevant to this whole process. 
>> They are passed down untouched. Although some auth frameworks like 
>> NTLM/Kerberos/Negotiate make several bad assumptions and need persistent 
>> connection pinning hacks (Squid 2.6, 2.7, and 3.1+ supported) in place 
>> to work over HTTP.
>> 
> 
> Right.  I am not wanting to touch logon from user to web servers.  The
> upstream proxy is a security/scanning thing that can apply different
> policies based on a user or group membership and also feeds the data
> into a reporting database.  For all this to work properly the username
> needs of the person making the request via squid needs to be presented
> to the upstream proxy.
> 
>>> Is there a configuration item I can enable to get the header?
>>> A bit of a search showed up nothing apart from some ICAP related 
>>> stuff.
>>> I cannot use ICAP for this application, I simply need the header.  
>>> Would
>>> the squid developers consider a patch if I developed one to add this?
>> 
>> No the header is not part of HTTP or any other protocol specification. 
>> It is an experimental header created for the use of ICAP plugins to 
>> Squid until such time as Squid can be re-written to use proper 
>> authentication to ICAP or ICAP helpers to not depend on the existence of 
>> a "user" label.
>> 
> 
> Well, I can tell you now that someone in the commercial space is abusing
> that header for their own ends.  Their documentation has clear
> instructions on how to add the header to a BlueCoat device and they have
> a .dll for MS ISA.  I don't want to name names in a public forum but I
> am happy to provide the info privately if you are interested.

I have a commercial web filtering and reporting product (although I think different from yours) that can also make use of the X-Authenticated-User header (as well as other user identification methods).

I have previously patched 3.0 versions of squid using the patch from http://www.squid-cache.org/mail-archive/squid-dev/201004/0199.html.

I'm sure it wouldn't be too hard to port to other versions of squid.

> 
> -- 
> Brett Lymn
> "Warning:
> The information contained in this email and any attached files is
> confidential to BAE Systems Australia. If you are not the intended
> recipient, any use, disclosure or copying of this email or any
> attachments is expressly prohibited.  If you have received this email
> in error, please notify us immediately. VIRUS: Every care has been
> taken to ensure this email and its attachments are virus free,
> however, any loss or damage incurred in using this email is not the
> sender's responsibility.  It is your responsibility to ensure virus
> checks are completed before installing any data sent in this email to
> your computer."
> 
> 




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux