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