Re: "negotiate" auth with fallback to other schemes

"Livio B" <lbsqdd_at_gmail.com> wrote in message
news:31f0d2c51003050619o6d3a78b9uaf319d8e63aa70d3_at_mail.gmail.com...
> 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.

I don't understand this part. Usually the kdc is on AD so how can NTLM work
and Kerberos not ?

>
>> 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
>
Received on Fri Mar 05 2010 - 21:03:25 MST