Re: "negotiate" auth with fallback to other schemes

2010/2/23 Henrik Nordström <henrik_at_henriknordstrom.net>:
>> So the idea is to extend the negotiate helper protocol so that the
>> helper can specify that its auth mechanism should no longer be offered
>> to the client (this might be useful for other mechanisms too). This
>> way it would be up to the helper to decide if its scheme should be
>> reiterated or not.
>
> I would say this fits better as an auth_param setting. Both Negotiate
> and NTLM protocols has a clear "Authentication has failed due to invalid
> credentials" message (NA ....).

Yes however, whether the client should get prompted again can make
sense (or not) regardless of the type of the returned message (NA, BH,
AF...).
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.
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.

> Why do the helper need to decide if the user should be prompted again?
> In which cases should the user get prompted again for Negotiate or NTLM
> after incorrect authentication?

I'm not sure: at the moment I cannot think of cases where the helper
decision cannot be taken beforehand as an auth_param.
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. Also letting the helper decide wouldn't
require a change to auth_param syntax (possibly breaking backward
compatibility) tough it clearly requires a small protocol extension.

>> My main doubt is where to keep the information about "disabled"
>> schemes. In my current test I keep a list of "still active" auth
>> schemes in the HttpRequest object. However the problem with this is
>> that the httprequest object is (seems to be) freed as soon as the
>> connection is closed. Therefore this works only for the first auth
>> reiteration, that is, this is what can happen:
>
> Simplest is to add a per-connection flag indicating that connection
> oriented auth (NTLM / Negotiate) should not be used for this connection.

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.

Thanks
Livio
Received on Wed Feb 24 2010 - 16:03:16 MST