Re: [squid-users] enabling X-Authenticated-user
On 9/03/2012 6:16 p.m., Brett Lymn wrote: On Thu, Mar 08, 2012 at 10:37:01AM +1030, Brett Lymn wrote: 1) The credentials being passed to the upstream are not rewritten - if I decode the basic auth it has my real password going to the upstream. And scratch this one too... if I use: cache_peer upstream.proxy parent 8080 7 login=*:password no-query default along with the external acl the username rewrite happens[1] so now the silly upstream logging actually works for both basic& kerberos authentication. [1] see line 1628 in http.cc - there is a check for peer_login == * and then it checks if there is an external ecl rewrite for the login details. Just below it on line 1644 was the case I was referring to where the username and password are set by the helper. But the * case will suit as well. Thanks for the patience& help Amos - I got there in the end. Huzzah for happy endings :) Amos
Re: [squid-users] enabling X-Authenticated-user
On Thu, Mar 08, 2012 at 10:37:01AM +1030, Brett Lymn wrote: > > 1) The credentials being passed to the upstream are not rewritten - if I > decode the basic auth it has my real password going to the upstream. > And scratch this one too... if I use: cache_peer upstream.proxy parent 8080 7 login=*:password no-query default along with the external acl the username rewrite happens[1] so now the silly upstream logging actually works for both basic & kerberos authentication. [1] see line 1628 in http.cc - there is a check for peer_login == * and then it checks if there is an external ecl rewrite for the login details. Thanks for the patience & help Amos - I got there in the end. -- 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."
Re: [squid-users] enabling X-Authenticated-user
On Thu, Mar 08, 2012 at 10:37:01AM +1030, Brett Lymn wrote: > > 2) For some unknown (to me) reason the upstream is prompting for auth > even though the basic auth header is there. It does not do this if I > have login=*:password but if I set login=PASS the upstream prompts. > Scratch this one - the stupid stupid stupid upstream seems to cache the username/cred pair after the first time it does a ldap lookup and will reject the authentication if the password. Once I cleared the caches this went away - when the auth rewrite works this won't be a problem. It looks like there is a setting on the upstream that will clear the cached entry if auth fails, why this isn't on by default is a mystery. -- 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."
Re: [squid-users] enabling X-Authenticated-user
On Wed, Mar 07, 2012 at 11:58:31PM +1300, Amos Jeffries wrote: > > cache_peer_access is a "fast" group access list. This is why suggested > never/always _direct lists for the testing. > Yep, me being dumb :) I did as you suggested and used the never_direct deny and my debug lines in the external helper fire _but_ there are two dumb things happening: 1) The credentials being passed to the upstream are not rewritten - if I decode the basic auth it has my real password going to the upstream. 2) For some unknown (to me) reason the upstream is prompting for auth even though the basic auth header is there. It does not do this if I have login=*:password but if I set login=PASS the upstream prompts. -- 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."
Re: [squid-users] enabling X-Authenticated-user
On 7/03/2012 4:49 p.m., Brett Lymn wrote: On Wed, Mar 07, 2012 at 03:44:23PM +1300, Amos Jeffries wrote: cache_peer option of "login=PASS", with the external_acl_type helper returning values in both user= and password= parameters. OK, I must be doing something dumb. I have the following in the config: cache_peer upstream.parent parent 8080 7 login=PASS no-query default external_acl_type user_rewrite_type children=1 ttl=900 %LOGIN /opt/local/squid/bin/user_rewrite.pl acl user_rewrite external user_rewrite_type cache_peer_access upstream.parent allow user_rewrite cache_peer_access is a "fast" group access list. This is why suggested never/always _direct lists for the testing. Amos
Re: [squid-users] enabling X-Authenticated-user
On Wed, Mar 07, 2012 at 03:44:23PM +1300, Amos Jeffries wrote:
>
> cache_peer option of "login=PASS", with the external_acl_type helper
> returning values in both user= and password= parameters.
>
OK, I must be doing something dumb. I have the following in the config:
cache_peer upstream.parent parent 8080 7 login=PASS no-query default
external_acl_type user_rewrite_type children=1 ttl=900 %LOGIN
/opt/local/squid/bin/user_rewrite.pl
acl user_rewrite external user_rewrite_type
cache_peer_access upstream.parent allow user_rewrite
But if I do an ACL debug I see:
2012/03/07 14:11:47.666| aclMatchExternal: "blymn": entry=@0, age=0
2012/03/07 14:11:47.666| aclMatchExternal: "blymn": queueing a call.
2012/03/07 14:11:47.666| aclMatchExternal: "blymn": return -1.
2012/03/07 14:11:47.667| aclMatchExternal: acl="user_rewrite_type"
2012/03/07 14:11:47.667| aclMatchExternal: user_rewrite_type("blymn") = lookup
needed
It seems like squid wants to call the external acl but it is not
happening.
user_rewrite.pl is in the right spot and contains:
#!/usr/bin/perl
#
$|=1;
open LOG,">/tmp/rewrite_log";
while () {
$username = $_;
chomp $username;
print LOG "Have username >$username<\n";
$username =~ s/^([A-Za-z]+)%5[cC]//;
($username, $blah) = split('@', $username);
print LOG "returning OK user=$username password=special\n";
print "OK user=$username password=special\n";
}
Nothing ever gets into /tmp/rewrite_log and doing an strace on the
process shows no activity.
--
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."
Re: [squid-users] enabling X-Authenticated-user
On 07.03.2012 15:44, Amos Jeffries wrote: On 07.03.2012 14:23, Brett Lymn wrote: Following up on myself... On Fri, Mar 02, 2012 at 01:59:27PM +1030, Brett Lymn wrote: At the moment I am looking at setting up a LDAP proxy for the upstream to query and then use login=*:password in squid. This should allow me to make the upstream proxy believe it is authenticating so that it has the username it wants. OK, I have good news/bad news about this approach. The good news is with the help of: [ snip the bad news :( ] So, it seems that I need to strip the username back to just a bare name. From what Amos said earlier it seems I can do this with an external acl, if I use this acl will the username be available for login=*? or do I need to use login=PASS? If I use login=PASS will I still get authentication on squid as well? (I really need squid to auth the client) or is there another way I can mangle the username to my needs? cache_peer option of "login=PASS", with the external_acl_type helper returning values in both user= and password= parameters. Oops. Forgot to answer your other questions. The above will not affect any authentication between the client and Squid. The two proxy-auth logins are separate. To be on the paranoid / safe side you can use another little trick: testing the helper in a "never_direct deny ..." or "always_direct allow ..." line. The allow/deny for those cases is meaningless, those *_access are only run when sending a request upstream, and are able to run slow helper lookups, and they are well out of the way of client authentication in http_access. Amos
Re: [squid-users] enabling X-Authenticated-user
On 07.03.2012 14:23, Brett Lymn wrote: Following up on myself... On Fri, Mar 02, 2012 at 01:59:27PM +1030, Brett Lymn wrote: At the moment I am looking at setting up a LDAP proxy for the upstream to query and then use login=*:password in squid. This should allow me to make the upstream proxy believe it is authenticating so that it has the username it wants. OK, I have good news/bad news about this approach. The good news is with the help of: [ snip the bad news :( ] So, it seems that I need to strip the username back to just a bare name. From what Amos said earlier it seems I can do this with an external acl, if I use this acl will the username be available for login=*? or do I need to use login=PASS? If I use login=PASS will I still get authentication on squid as well? (I really need squid to auth the client) or is there another way I can mangle the username to my needs? cache_peer option of "login=PASS", with the external_acl_type helper returning values in both user= and password= parameters. Amos
Re: [squid-users] enabling X-Authenticated-user
Following up on myself... On Fri, Mar 02, 2012 at 01:59:27PM +1030, Brett Lymn wrote: > > At the moment I am looking at setting up a LDAP proxy for the upstream > to query and then use login=*:password in squid. This should allow me > to make the upstream proxy believe it is authenticating so that it has > the username it wants. > OK, I have good news/bad news about this approach. The good news is with the help of: http://www.openldap.org/lists/openldap-software/200010/msg00097.html http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/13.html I was able to create a shell backend - the script in the first link didn't work well with the version of openldap I had but a merging of bits of scripts from both pages gave me a working lookup. My shell script just returns "OK" to a bind request. This gives the upstream proxy what it wants to do "authentication". In the squid.conf I just use "login=*:password" to feed the username and fixed password to the upstream. This works fine, squid passed up the username, upstream looks in ldap, ldap says "ok". Happy days. The bad news is even though the username gets validated by the upstream when it does the logging only the accesses using basic authentication work - accesses using kerberos authentication work _but_ the username is missing from the upstream reporting logs. It _is_ happy with the auth but for some reasons best known to itself the details don't get fed into the log *sigh* I did a bit of a troubleshoot on this and found that when using kerberos the username is "u...@our.ad.DOMAIN", my ldap script just strips the domain and feeds back the DN for the user fine but the upstream won't report the user to it's logging server. I tested this by changing the squid.conf to have "login=*@OUR.AD.DOMAIN:password" and then the upstream fails to log the user when basic authentication is used just like kerberos case. So, it seems that I need to strip the username back to just a bare name. From what Amos said earlier it seems I can do this with an external acl, if I use this acl will the username be available for login=*? or do I need to use login=PASS? If I use login=PASS will I still get authentication on squid as well? (I really need squid to auth the client) or is there another way I can mangle the username to my needs? -- 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."
Re: [squid-users] enabling X-Authenticated-user
On Fri, Mar 02, 2012 at 03:29:22PM +1300, Amos Jeffries wrote: > > You really need that functionality from 3.2 then. > * login=NEGOTIATE to have one key representing your Squid and all > users going through it. Or at least one key peer cache_peer line ;) Unfortunately I really need to stick with a stable version of squid, I want to make this setup production soon-ish. > Or > * login=PASSTHRU to act as a transparent proxy (HTTP meaning) with > regards to proxy-auth. NTLM passthru fails if squid is authenticating > due to NTLM multi-stage handshake. But Kerberos works fine with both > layers validating and rejecting invalid keys (assuming they are both > checking it against the same AD control servers). > Hmmm - I just tried login=PASSTHRU and I had an authorisation required back from the upstream proxy for both basic & kerberos auth. At the moment I am looking at setting up a LDAP proxy for the upstream to query and then use login=*:password in squid. This should allow me to make the upstream proxy believe it is authenticating so that it has the username it wants. > Despite any claims they might make, X-Authenticate-User would not work > for a properly authenticating upstream either. Since the data in it > lacks the password/token it cannot be re-authenticated, and is easily > forged. At worst they are claiming authentication but not actually doing > any when X-Authenticate-Info is received (scary thought). > Yes, I think that all they are doing is picking out the username and doing an LDAP lookup on AD for the DN and making some decisions based on that. In my case this is not so bad, I can firewall off access to the upstream proxy so only the squid proxies can access it (ultimately, the upstream may just be a xen guest on the squid proxy machine which simplifies things further in terms of access). -- 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."
Re: [squid-users] enabling X-Authenticated-user
On 2/03/2012 11:53 a.m., Brett Lymn wrote: On Thu, Mar 01, 2012 at 10:02:06PM +1300, Amos Jeffries wrote: Can't you just support proper authentication? I can but I have problems if I try and use kerberos for authentication. I have kerberos working fine with squid, the auth works ok - I even have it working correctly with the squids behind a load balancer *but* when I turn authentication on at the upstream proxy the authentication fails at the upstream. I can see in the status page for the upstream that kerberos is being tried but failing probably because the principal name is wrong but I am not sure about that. By the looks of it they are using samba on the upstream to perform the authentication. I don't know if it would work finding the keytab and adding the keys that squid uses... that may have a chance of working... maybe. You really need that functionality from 3.2 then. * login=NEGOTIATE to have one key representing your Squid and all users going through it. Or at least one key peer cache_peer line ;) Or * login=PASSTHRU to act as a transparent proxy (HTTP meaning) with regards to proxy-auth. NTLM passthru fails if squid is authenticating due to NTLM multi-stage handshake. But Kerberos works fine with both layers validating and rejecting invalid keys (assuming they are both checking it against the same AD control servers). Despite any claims they might make, X-Authenticate-User would not work for a properly authenticating upstream either. Since the data in it lacks the password/token it cannot be re-authenticated, and is easily forged. At worst they are claiming authentication but not actually doing any when X-Authenticate-Info is received (scary thought). Amos
Re: [squid-users] enabling X-Authenticated-user
On Fri, Mar 02, 2012 at 12:41:11AM +1300, Amos Jeffries wrote: > > You really want to trust a tutorial which begins with "Enable SSL > interception on the proxy server."? > Unfortunately, want has little to do with this. I get no say in whether or not we have what we have I am just the bunny that has to make it work somehow. > There really is no need for a proxy to use write-access to headers and > client requests. The servers have PICS labeling or other newer rating > systems available that the proxy can read and enforce site-wide policy > for far easier. > http://vancouver-webpages.com/PICS/HOWTO.html#tools > > Too many different sized wheels on that old cart. > Yep, there are many but those wheels don't address some of the concerns of the people driving this. They want to do content scanning amongst other things. If it were just URL filtering it would be pretty easy. > > Looked at, yes. Argued over, probably. Accepted, depends on how the > audit and voting process goes. We are very democratic. > OK - if I try this path I will get myself onto squid-dev and gauge some reactions first I guess. > Personally I'm against the nasty uses naive people put it to without > considering the consequences more than the feature itself. Adding it is > the top of a slippery slope of feature requests we have managed to > mostly avoid so far. > Totally understand - I do free software development in my spare time too and know exactly what you are talking about. -- 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."
Re: [squid-users] enabling X-Authenticated-user
On Thu, Mar 01, 2012 at 10:02:06PM +1300, Amos Jeffries wrote: > > Can't you just support proper authentication? I can but I have problems if I try and use kerberos for authentication. I have kerberos working fine with squid, the auth works ok - I even have it working correctly with the squids behind a load balancer *but* when I turn authentication on at the upstream proxy the authentication fails at the upstream. I can see in the status page for the upstream that kerberos is being tried but failing probably because the principal name is wrong but I am not sure about that. By the looks of it they are using samba on the upstream to perform the authentication. I don't know if it would work finding the keytab and adding the keys that squid uses... that may have a chance of working... maybe. Unfortunately, the upstream is pretty much a commercial black box, I have little control over what it does nor what it requires. I can only go by the documentation they offer. From what I can see of the logging and so forth it seems that all the upstream does is take the username and do a LDAP lookup to get the distinguished name, it can then use that to check group memberships or look for user specific actions that may be configured. Again, in my case, since everything is using the same Active Directory the chances of squid authenticating and the upstream not finding the user is slim - anyway, in my case, this would not be a total disaster it would simply mean the user gets a set of default actions applied to them. > > I'm reluctant to add the header because the data is already transmitted > in the authentication headers. > Yes, understood. The problem I have is that, as I said, this upstream is pretty much a black box so they set the rules and they won't change them. Hell, the software insists on running on a 32 bit OS and asking about WTF the 64bit version was was met with pretty much silence. > 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. > Definitely need a real password if the upstream is authenticating.. hmmm or maybe not...they do give the option of authentication against an ldap server. I wonder if I could set up a LDAP proxy that would fake up the authentication, it could check the user exists in AD and just OK the auth. I am happy to do anything up to and including coding that will get me out of this hole - if I cannot make this work somehow then I am going to have to dump squid and try and get the stupid upstream to do all the clever things that we currently do with squid, this would be a world of hurt that will continue to give for the life of the damned things. > 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. > OK but can I manage to get a password when using negotiate? I didn't think so but I am usually wrong. People here view an authentication popup box as an error when they are browsing so unless I can make it work with integrated windows authentication it won't be an option. -- 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."
Re: [squid-users] enabling X-Authenticated-user
On 02.03.2012 00:06, Michael Hendrie wrote: On 01/03/2012, at 7:32 PM, Amos Jeffries wrote: On 01.03.2012 18:06, Brett Lymn wrote: On Thu, Mar 01, 2012 at 03:17:43PM +1030, Michael Hendrie wrote: 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. I would also like to see a feature for "insert_user_defined_header" not only of X-Authenticated-User but would be useful for other web apps I've come across (Google and YouTube) using non-standard HTTP header's that I've had to create patches for...see the following URLs: http://support.google.com/a/bin/answer.py?hl=en&answer=1668854 http://support.google.com/youtube/bin/answer.py?hl=en&answer=1686318 You really want to trust a tutorial which begins with "Enable SSL interception on the proxy server."? There really is no need for a proxy to use write-access to headers and client requests. The servers have PICS labeling or other newer rating systems available that the proxy can read and enforce site-wide policy for far easier. http://vancouver-webpages.com/PICS/HOWTO.html#tools Too many different sized wheels on that old cart. If there were code submission to the dev mailing list would these get looked at or is there no chance of a "insert_user_defined_header" feature being included? Looked at, yes. Argued over, probably. Accepted, depends on how the audit and voting process goes. We are very democratic. Personally I'm against the nasty uses naive people put it to without considering the consequences more than the feature itself. Adding it is the top of a slippery slope of feature requests we have managed to mostly avoid so far. Amos
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
Re: [squid-users] enabling X-Authenticated-user
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). > > 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. -- 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."
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." > >
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."
Re: [squid-users] enabling X-Authenticated-user
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? 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. 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. 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. If your other proxy needs to play with the users website login it is fully responsible for breaking into the authentication itself. Squid is not going to help with that abuse. 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. Amos
[squid-users] enabling X-Authenticated-user
I have an application that pays attention to the X-Authenticated-User header. I need to use this application as an upstream proxy and need to have the user authentication passed from squid through to this application. I know about the login=PASS cache_peer directive but I am wondering how that plays with negotiated authentication schemes like kerberos. 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? -- 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."
