Re: "negotiate" auth with fallback to other schemes

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
Received on Fri Mar 05 2010 - 15:23:15 MST