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