Re: "negotiate" auth with fallback to other schemes

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