We have OAuth and we’re strong

It’s been a while since I posted anything related to the Akonadi EWS resource, but that does not mean that the project is abandoned – development is ongoing, albeit a little slow.

Today’s episode of “what’s going on in the EWS world” is all about authentication.

From the early days of Akonadi EWS interacting with Microsoft authentication mechanisms was a bit on the hard side. Anybody who is wondering why is invited to look into Samba history & development, which should be a good enough indication of the problems we’re dealing with here. This mostly impacted NTLM authentication, which had to be patched in KIO in order to work properly (NTLM version 2).

OAuth2

With the move to the cloud and introduction of Office 365 Microsoft went into more modern authentication methods. One of them is OAuth2, which was already widely used in other services, such as GMail.

One specific thing about OAuth2 is that you need to register an application, for which authentication is taking place. In case of Office 365 this means an Azure account is needed to register an application.

Evolution, which has been supporting OAuth2 chose to let the user to provide its own registered application, which effectively means that the OAuth2 authentication backend is non-functional out-of-the-box. User interaction is needed in order to enable it.

For Akonadi EWS I chose to register my own app, which means that OAuth2 should be working without any further user actions beside supplying a password.

The application registration should be working for everyone as it was registered as a global app. It is however possible that an administrator of a corporate Office 365 account may either explicitly block it or use a whitelist of apps that have access to Exchange. Should this ever happen a back door is left behind in the EWS Resource – similar to Evolution it is possible to configure a different app identifier to be used instead of the default. This can be done by manually editing the ~/.config/akonadi_ews_resource_?rc file (? will be a number starting from 0) and adding a new line:

OAuth2AppId=<app-uuid>

In case of very stubborn admins, the ultimate way to work around obstacles is to use the app id from Microsoft Outlook (d3590ed6-52b3-4102-aeff-aad2292ab01c).

Strong authentication

Experienced sysadmins have already noticed that using just a username and password for authentication is proving to be not sufficient. For that purpose additional authentication steps, such as MFA (Multi-Factor Authentication) have been deployed.

Another option is to establish some form of trust against the device that is used for authentication, which ensures that access from a company owned or managed device is considered safe.

For the latter purpose Microsoft defined an additional authentication protocol called Public Key Authentication Protocol (PKey) described in [MS-PKAP]. It is used during OAuth2 authentication to prove possession of a device-specific private key. This key is being generated and registered with the Azure Directory during device enrolment into the corporate directory. This can be done by performing a Workplace Join from Windows 10 or using the InTune app on Android.

From what I can find it looks like Akonadi EWS is the first open-source implementation of the PKey authentication protocol.

Why is this so important? Depending on the security policy defined by the corporate administrator it may have decided to block access to Office 365 from outside the company network for unregistered devices or alternatively require additional authentication steps (MFA) when connecting from outside the office. By setting up Private key authentication it is possible to be seen as trusted in the same way as Windows users.

So far there are no open-source tools to register such a certificate/private key with the Azure Directory. Fortunately however the protocol has been published and I will be working on such a tool/script.

Both OAuth2 and Public/Private Key Authentication are implemented and will hopefully be part of KDE Applications 18.12 release.

What’s next on the table

SAML

I’m not done with authentication yet. There is one more authentication goodie in the pipeline.

While OAuth2 is a nice and generic solution it brings a slight drawback – you need to type your password and/or MFA token every two weeks or so.

For Office 365 and Azure Directory users there is however another way in – based on ADFS SAML authentication. This method is non-interactive and can be used with just the username/email and password. There is a catch however – if the administrator has chosen to require strong authentication when connecting outside of trusted network this method will not work unless it is used together with PKey authentication.

EWS SOAP API refactoring

In the current implementation all EWS SOAP requests have been written manually. They are in many ways copies of each other with lots of boilerplate code.

The plan is for this to be replaced by generated code.

This is a significant task to do, however when it’s done it will open up possibilities for the long awaited full calendar support and more.