This is more of a duplicate of bug #587145, rather than depends on it.

Well, we still have work to do on the EWS side to support it, once libsoup does.

Created attachment 255435 [details] [review]
proposed ews patch

for evolution-ews;

This adds kerberos authentication to EWS (it requires a change on eds side too, which just follows). I do this without libsoup's support, by reusing CamelSaslGssapi implementation.

There is one thing I do not understand, with NTLM, once the negotiation is over, the next messages on the session are served without re-authentication, but with Negotiation, the server claims that the user is not authorized and I'm forced to ask for the ticket again. This is for each single SoupMessage added into the EEwsConnection soup session. May I do anything wrong?

Created attachment 255437 [details] [review]
proposed eds patch

for evolution-data-server;

This publicizes API on CamelSaslGssapi, to be able to use it without actual CamelService instance. This is necessary, to be able to reuse the code in calendar and book backends.

Created attachment 255438 [details] [review]
proposed ews patch ][

for evolution-ews;

Oops, only one change, unref 'connection' in a dedicated thread. I've just got a crash:
> (evolution:13729): GLib-ERROR **: file gthread-posix.c: line 1162
> (g_system_thread_wait): error 'Resource deadlock avoided' during
> 'pthread_join (pt->system_thread, NULL)'

Milan, I love you and I want to have your babies.

(In reply to comment #3)
 is one thing I do not understand, with NTLM, once the negotiation is
> over, the next messages on the session are served without re-authentication,
> but with Negotiation, the server claims that the user is not authorized and I'm
> forced to ask for the ticket again. This is for each single SoupMessage added
> into the EEwsConnection soup session. May I do anything wrong?

That's odd. I don't see why that ought to be the case. When I'm home from Linux Plumbers Conf next week I'll try to experiment a little with this, and read the specs and compare with libcurl etc.

Does it help if we actually start using the *cookies* the Exchange server attempts to set? And what is this 'Persistent-Auth:' header?

I see this (final message of one request, first of the next on the same socket)...

< HTTP/1.1 200 OK
< Set-Cookie: exchangecookie=793ad0b8adac4c288435a3a3ef1d3d66; expires=Sat, 20-Sep-2014 19:04:04 GMT; path=/; HttpOnly
< WWW-Authenticate: Negotiate YIGDBgkqhkiG9...
< Persistent-Auth: false
...
</s:Envelope>

(evolution:2547): camel-CRITICAL **: sasl_set_service: assertion `CAMEL_IS_SERVICE (service)' failed
> POST /EWS/Exchange.asmx HTTP/1.1
> Soup-Debug-Timestamp: 1379703845
> Soup-Debug: SoupSessionAsync 1 (0x1ba76f0), ESoapMessage 24 (0x1b8fc20), SoupSocket 1 (0x2567e10)
> Host: irsmsx103.ger.corp.intel.com
> User-Agent: Evolution/3.8.6
> Connection: Keep-Alive
> Content-Type: text/xml; charset=utf-8

(This is your patches on 3.8.5, so if you aren't seeing that same CRITICAL message then perhaps that's a backport issue)

http://blogs.msdn.com/b/benjaminperkins/archive/2011/10/31/kerberos-authpersistnonntlm-authentication-request-based-vs-session-based-authentication.aspx

(In reply to comment #6)
> (evolution:2547): camel-CRITICAL **: sasl_set_service: assertion
> `CAMEL_IS_SERVICE (service)' failed

Hrm, that might be an overlook on my side. I realized that I did not attach the same eds patch as I had in use here. I'll re-evaluate it here and update patches accordingly.

Thanks for the link too, I'll look on that.

(In reply to comment #7)
> http://blogs.msdn.com/b/benjaminperkins/archive/2011/10/31/kerberos-authpersistnonntlm-authentication-request-based-vs-session-based-authentication.aspx

Nice, so it's up to admins to decide, there is nothing what evo-ews can do about it. Good to know.

Created attachment 255611 [details] [review]
proposed eds patch ][

for evolution-data-server;

The same as before, only added check for the runtime warning to not claim when CamelSASL has set NULL 'service' (I hoped it'll not be called when I do not set it explicitly, but the GObject machinery calls it anyway, thus bad luck for me).

Anyway, with these two patches it works as expected for me. Could you give it a try on your side when you've time, and if it'll work for you too, then I'll commit for 3.12. Thanks in advance.

Created commit 82b0282 in eds master (3.11.1+)
Created commit 56c1b7b in ews master (3.11.1+)