Re: [Evolution-hackers] Camel Authentication Changes

[Matthew Barnes <mbarnes redhat com>]

On Thu, 2011-10-20 at 01:14 +0100, David Woodhouse wrote: 
> This looks like a good idea, and cleaning up the various ways that the
> providers were behaving differently in that authentication loop (and
> calling directly out to the GUI) is a good thing.
> 
> I looked at those recently when implementing the ->try_empty_password()
> SASL methods for automatic NTLM auth, and I take my hat off to you for
> finding a way through the mess.
> 
> Having said that, I do think we need to adjust this approach to deal
> with authentication as a *reactive* thing, not *proactive*. It *used* to
> be reactive, but you changed it as a side-effect of your improvements.
> 
> The point is that we authenticate ourselves *if* and *when* the server
> asks us to. We cannot know in advance whether we're going to need a
> password or not.

We discussed this at length on IRC last night and I'm still digesting
all the implications of auth cases I hadn't considered.  I'm hoping
that, at least for the time being, we can get by with the current API
with only some tweaks to the authentication loop logic.

Down the road I'm perfectly happy to revisit this, and even break APIs
if needed to do it right, but right now Red Hat is pressuring me to get
this account rewrite branch of mine finished as quickly as possible.  So
for now I really have to move on from this.


> That's fine at the moment, but the fact that we have to explicitly
> choose *one* mechanism in advance ought to be considered a bug. In the
> future, we ought to simply try *any* of the methods that the server
> offers today, in some order of preference. So we could try Kerberos,
> fall back to NTLM, etc. These changes seem to have made that harder to
> fix.

I think we could achieve this with multiple calls to
camel_session_authenticate_sync() with a different mechanism name each
time ("kerberos", "ntlm", "login"), and making sure the session logic
knows when to loop and when to bail out if an auth attempt fails.

It already kinda does that by looking up the CamelServiceAuthType struct
associated with the mechanism name (if one was given) and checking its
'need_password' flag.  If FALSE, it does ONE authentication attempt and
bails on failure (instead of looping).  After which you could possibly
call camel_session_authenticate_sync() again with a fallback mechanism
name.

Problem is when a mechanism name is NOT given, as is the case for most
HTTP-based backends, or when 'need_password' is TRUE, it assumes you'll
*will* need a password to authenticate and prompts if one is not found
in the keyring (which I understand now to be a bad assumption).  That's
the part that needs tweaking, for now.


> It looks like it'll always ask for a password for HTTP-based backends,
> but those have similar options; they may authenticate with Kerberos, or
> with automatic-NTLM, or with cookies... or they *may* actually decide
> that they need a password today.

Right.  I've made similar changes to the addressbook and calendar
backends on my branch, more of which are HTTP based, and what I did
there was first try to run some initial inconsequential operation ("list
calendars" or some such) with no auth header at all, and if that fails
with a "401 Unauthorized" *then* initiate authentication in a similar
manner to camel_session_authenticate_sync().

I realize that doesn't cover all the use cases you were throwing at me,
particularly the server password suddenly changing in the middle of a
session, but perhaps that approach, in combination with the tweaking I
mentioned above, would address the premature password prompt in EWS for
the time being?