Livio B wrote:
Hi,
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..
Well that would have to be a parameter to the helper command.
So, to summarize, adding this fall-back option would either require 1)
a backward compatible protocol update, or 2) a backward compatible
auth_param syntax extension.
Option 1) would have the advantage that the helper could behave
differently basing on client responses;
option 2) would have the advantage that it doesn't require changes to helpers.
You are clearly advocating option 2.
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.
This is not completely fair. Kerberos may fail just because the client
has no connectivity with the KDC, and in this case NTLM could be a
useful second choice.
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.
Agree.
So I'll work on a patch to support a new auth_param option (any
suggested syntax?) and tracking the list of "disabled" protocols in
the "request" or "connection" object, keeping the connection open even
when authentication fails.
Regards,
Livio
All of this discussion sounds a lot like the open feature request to
make particular authentication schemes AC-based.
That feature would be implementing a configuration something like this:
auth_param type allow|deny acllist ...
the effect being that it would allow or prevent the auth scheme being
added to the response headers.
This would allow both what you want (based on helper reply + request
auth type) and other things like user-agent (dropping negotiate as a
choice for IE6, or non-basic for Java 1.4) or specific schemes for
specific LAN networks.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE24
Current Beta Squid 3.1.0.17
