ons 2010-02-24 klockan 17:03 +0100 skrev Livio B: > For example, even when kerberos auth succeeds (AF message), still > squid acls can deny access to that authenticated user. And the helper > has no way to know that. Depending on the scenario, it may make sense > to prompt the user again or not.
That's controlled in http_access. > In particular, if I want only transparent auth, it wouldn't make sense > to retry the authentication because either the helper would get the > same SSO (denied) credentials or the user would get prompted (which I > don't want). On a different scenario, where it is ok to prompt the > user for alternative credentials, it would make sense to retry the > negotiate. Yes, and how would the helper know when this is? That knowledge is better in Squid.. > However letting the helper decide seems more dynamic and allows for > decisions based on the answer from the client, something that wouldn't > be possible with auth_param. In reality the helpers don't know much of the auth protocol, just relaying data to some auth backend. > Also letting the helper decide wouldn't > require a change to auth_param syntax (possibly breaking backward > compatibility) How would it break backward compatibility? It's a new option. Old configs without the option will still work the same.. > tough it clearly requires a small protocol extension. Which breaks compatibility, and requires each and every helper to get updated with configuration directives to allow the admin to decide how the helper should react.. > This seem a little unflexible. For example, currently there is no > helper that can handle both negotiate/kerberos and negotiate/ntlm so > if I need to support both I need a negotiate helper and a NTLM helper > and might want to disable just one. And of course new protocols can > eventually surface. Is the flexibility really needed in this case? Negotiate and NTLM is very closely related, and will always connect to the same backend (windows ADS / domain controller) at least in sane setups. If one fails then there is very limited use of trying the other. Exception is browser bugs, but those are better handled by scheme acls to block for example the Negotiate scheme for known broken browsers. Theoretically there may be value in fallback from http digest to http basic auth in some cases, but neither of those is single-sign-on and in my experience since those are not SSO to begin with the method of canceling the first to get to the next one works about as well as we can get. Additionally I as a user and network admin would not be comfortable with digest auth automatically falling back on basic on authentication failure, due to the non-existing security of basic auth. If the client supports digest then it should stick to that until the user says otherwise. Regards Henrik