2010/2/23 Henrik Nordström <hen...@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