Re: "negotiate" auth with fallback to other schemes

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
Received on Thu Feb 25 2010 - 21:46:49 MST