Subject: bug#50113: Excorporate: Communicating with domain that requires SSO?

From: Thomas Fitzsimmons <[email-masked]>
Date: Mon, 13 Mar 2023 12:30:51 -0400

Hi,

ParetoOptimal <[email-masked]> writes:

>> As a starting point, are you able to make DavMail retrieve your calendar
>> items? 
>
> Hello! I'm able to use davmail successfully, but I'm not sure how to
> verify how my calendar is working.

OK, thanks for following up.

> I guess I'll try following
> https://davmail.sourceforge.net/thunderbirdcalendarsetup.html and verify
> it works with thunderbird?

Sure, that'd be proof that something is working.

> I did try going to the caldav url fom the instructions above:
>
> http://localhost:1080/users/[email-masked]/calendar
>
> But i received an error, so it's very possible that may not work or may
> need a new url.
>
>> If yes, check if it uses, or can be configured to use, EWS
>> rather than WebDAV.
>
> You mean if davmail can be configured to expose the calendar as EWS
> rather than WebDAV or caldav format right? Because excorporate is only
> capable of consuming EWS?

No; my eventual goal is to help you get Excorporate communicating
directly with the Exchange server, without needing DavMail.  Today,
Excorporate can only do that using EWS, not WebDAV.

I was asking whether you can configure DavMail to use EWS, instead of
WebDAV, to communicate with the Exchange server.  If you can get DavMail
communicating with the Exchange server using EWS (independent of
Excorporate), then that proves a) your administrators allow access to
the EWS APIs, and b) DavMail can successfully authenticate to your
Exchange server.

If (a) works, and (b) works using OAuth 2.0, then that's what this bug
report intends to eventually provide support for in Emacs.

If (a) does not work, then either Excorporate will not work, or someone
could add WebDAV support to Excorporate.

>> If you can make DavMail + EWS work somehow, then
>> there's hope for Excorporate in your environment, with some oauth2.el
>> integration effort.
>
> If DavMail is working, what is the need for oauth2.el?

Interesting timing; I just pushed the start of url-http-oauth
yesterday, but it's only the skeleton so far:

   https://git.sr.ht/~fitzsim/url-http-oauth

url-retrieve operations are buried deep within Excorporate and
soap-client.  So oauth2.el's crucial TODO item about integrating with
the URL library is relevant.  It was never clear to me how to use
oauth2.el to good effect, assuming a dependence on `url-retrieve'.  So
I'm writing another mode, similar to url-http-ntlm.  This new mode will
use the encrypted auth-source database to store Bearer tokens instead of
plstore.

Initially I will validate the mode with a demo package that
authenticates to https://meta.sr.ht/query.  Sourcehut has implemented
OAuth 2.0 in a perfectly Free Software-friendly way.  So I will validate
that it works first.

This should result in a URL add-on library that is well-integrated with
Emacs, and maintainable, at least for one hospitable OAuth 2.0 provider.

> It seems like a sensible lowest-effort way to get excorporate working
> with SSO would be to totally depend on DavMail.

One of Excorporate's main mandates is to have no middle-process.
Similar to how Gnus doesn't need an external process to communicate with
IMAP and SMTP servers.  At this point I consider an
Excorporate-to-DavMail integration a non-goal; it's not something I'd be
interested in maintaining, anyway.

Definitely try to get Emacs working with your calendar, and depend on
DavMail exclusively.  But there are probably better ways to do that,
which don't involve Excorporate at all.

> I tried to research whether this is possible, but unsurprisingly
> searching "davmail calendar EWS" gave poor results.

It seems to be covered here (via Searx):

   https://davmail.sourceforge.net/faq.html

A search for "davmail calendar Excorporate" would probably eventually
lead you back to this bug report.

Thomas