Exchange REST für Mail, Kontakt, Termin

Auf der MEC2014 wurde ein neuer Weg für den Zugriff auf Postfachinhalte jeder Art vorgestellt. Ich gehe davon aus, dass dieser Zugriff auch für Exchange On-Premise bald zur Verfügung stehen wird. Auslöser ist sicher, dass in der Cloud keine Zugriffe per MAPI/RPC oder CDO mehr möglich sind, und RPC/HTTP einen größeren Overhead hat. Gefragt sind also einfache Wege auf die Informationen zuzugreifen und EWS ist vielleicht nicht einfach genug. Da sind REST und JSON die neuen Schlagworte. Und der Zugriff ist so schlank, dass man sogar einen RaspberryPI oder Arduino dafür als Client einbinden kann.

Das virtuelle Verzeichnis /API ist mit Exchange 2016 CU3 erstmals im IIS-Manager aufgetaucht.
Das Verzeichnis "/REST" war aber schon seit CU1 in den Installationsquellen aber wurde wohl vorher noch nicht eingebunden

Basis

Die meisten Lösungen erfordern nur wenige Basisfunktionen, die möglichst auf jedem Client zur Verfügung stehen sollten. HTTP bzw. HTTPS ist das präferierte Protokoll und die Parameter werden einfach per Parameter übergeben. Und dann könnte das wie folgt aussehen:

Die Hostnamen in den URLs hier sind keine realen Adressen und funktionieren natürlich nicht und selbst wenn ist natürlich eine Authentifizierung erforderlich.

Sie sehen schon, wie einfach so eine Anfrage ist, wenn der Client sich erst einmal "authentifizieren" und die Rückantworten interpretieren kann. Die API lässt sich für den Zugriff auf die eigene Mailbox als auch auf eine andere Mailbox nutzen. Man muss nur den Pfad entsprechend anpassen:

Auf der MSDN gibt es weitergehende Artikel:

Auf dem Server

Wie Microsoft die Rest-API auf Office 365 umgesetzt hat, kann man leider nicht einsehen. Aber da die Rest API mittlerweile auch auf dem "On-Premise-Server" vorhanden ist, können Sie hier natürlich schauen. Das virtuelle Verzeichnis "/API", gibt es sowohl auf dem Frontend Server als auch auf dem Backend:

  • Virtuelles Verzeicnis /API auf dem Frontend
  • Virtuelles Verzeichnis auf dem Backend

Hier noch ein paar weitere Details:

  Frontend Backend
Basisverzeichniss

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\Rest

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\rest

ApplicationPool

MSExchangeRestFrontEndAppPool

MSExchangeRestAppPool

Authentication

Anonymous
Windows Authentication

Anonymous
Windows Authentication

SSL Setting

Required, Ignore Client Cert

Required, Ignore Client Cert

Verwaltung per PowerShell

Auch wenn es seit CU3 die virtuellen Verzeichnisse im IIS gibt, so liefern die entsprechenden PowerShell Commandlets auch mit CU3 noch keine Rückgabe.

[PS] C:\Windows\system32>get-command *-RestVirtualDirectory

CommandType     Name
-----------     ----
Function        Get-RestVirtualDirectory
Function        New-RestVirtualDirectory
Function        Remove-RestVirtualDirectory
Function        Set-RestVirtualDirectory

Das virtuelle Verzeichnis ist schon vorhanden aber nicht als "RestVirtualDirectory" gelistet. Ich bin gespannt, ab wann diese Funktion "offiziell" vorhanden ist.

Authentifizierung

In der Office 365 Umgebung geht das natürlich nicht einfach per "Benutzername/Kennwort", denn in der Cloud sind andere Verfahren, z.B. ADFS, üblich. Ihr Client wird sich daher beim Zugriff einen 401-Fehler einfangen, in dem Der Weg zur Authentifizierungsserver hinterlegt ist. für den Einsatz On-Premise hingegen wird man die Anmeldung gleich als HTTP-Anmeldung mit übergeben.

Beispiele folgen später.

Rückmeldung

Abhängig von Programm, das sie nutzen, sind die Rückgaben bereits aufbereitet. Wer z.B. mit der PowerShell ein "Invoke-RESTMethod" nutzt, bekommt ein schöne PowerShell Objekt zurück, welches sehr einfach ausgewertet werden kann.

Beispiele folgen später

Offen: App Passwort

So schön die Anmeldung per Credentials oder per ADFS-Tokens ist, so risikobehaftet ist dies natürlich insbesondere für Dienste, die auf Postfächer zugreifen wollen. Wie schon auf App Password beschrieben, fehlt mir auch hier die Option ein sehr langes Kennwort für eine Applikation zu hinterlegen, welches dann auch nur für diesen Zugriff genutzt werden kann.

Beispiele folgen später.

Offen: Impersonation

Eine der großen Stärken von EWS ist die Möglichkeit der Impersonation, d.h. sich als anderer Benutzer auszugeben. Ich bin gespannt ob und wann das auch per REST möglich sein wird.

Weitere Links