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

On 01.03.2012 18:06, Brett Lymn wrote:
> On Thu, Mar 01, 2012 at 03:17:43PM +1030, Michael Hendrie wrote:
>>
>> 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).

Can't you just support proper authentication?
  The proxy-auth headers only exist between your app and the downstream
client/proxy app, and are intended for exactly the purpose of securely
transmitting details like username. Validation of the client supplied
data is up to you, at risk not being able to identify lies unless you
do. But that may be fine for your apps purpose and is a risk you face
already with the custom X- header.

>>
>> 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.
>>
>
> Thanks, that does save me a bit of work but I am reticent of doing an
> "unofficial" patch for fear of it breaking when I upgrade squid and
> having to respin the patch - I can easily do the respin but others
> may
> not be able to do this which is a bit of a problem.
>
> I think Amos has been pretty clear that this won't be a supported
> header
> and I can understand the reasoning for that. Having a look at the
> instructions for the BlueCoat it started me thinking that maybe a way
> to
> approach this in squid is to do something similar - allow a user
> defined
> header to be inserted. Something like:
>
> insert_user_header X-Foo-Bar %u
>
> Where %u is replaced by the username - if the username is null the
> header is not inserted. This would mean that the squid code never
> has
> any non-standard headers in the code base but users can happily shoot
> holes in their own feet.

I'm reluctant to add the header because the data is already transmitted
in the authentication headers.

Squid does have a little issue automatically mapping
Kerberos/NTLM/Digest usernames into a Basic auth because we cannot
easily be sure if a fake password is acceptable or real one needed by
the upstream. I'm quite happy to accept patches which add that mapping
ability to Squid in a secure way.

NP: an external_acl_type helper can return the key-pairs "user=X
password=Y" (both needed to do this) to associate some credentials to
the request. These are available to login=PASS for relay upstream in the
Basic auth format.

Amos
Received on Thu Mar 01 2012 - 09:02:09 MST