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

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.

-- 
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."