Re: [squid-users] enabling X-Authenticated-user

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."
>
>
Received on Thu Mar 01 2012 - 04:47:47 MST