Sicherheitsanforderungen für Nachrichten mit Aktionen in Office 365

Das Schützen von E-Mails mit Aktionen gestaltet sich einfach und problemlos. Es gibt zwei Phasen innerhalb der End-to-End-Erfahrung, für die Sicherheitsanforderungen für Ihren Dienst vorgegeben sind, wenn Nachrichten mit Aktionen in Office 365 unterstützt werden. Die Phasen und die entsprechenden Anforderungen lauten wie folgt:

  1. Sendephase: Es gelten folgende Voraussetzungen für Ihren Dienst, um Nachrichten mit Aktionen zu senden:
    • Wenn Sie E-Mails mit Aktionen verwenden, stellen Sie sicher, dass Ihre E-Mail-Server SPF und DKIM als zusätzliche Schutzvorrichtung gegen Absender-E-Mail-Spoofing (Großteil der E-Mail-Systeme tun dies bereits) nutzen. Beachten Sie, dass dies nicht für Connectornachrichten gilt.
    • Der Dienst muss bei Microsoft registriert sein.
    • Die Aktions-URL muss HTTPS unterstützen.
  2. Phase der Aktionsverarbeitung: Wenn Sie eine Aktion verarbeiten, sollte Ihr Dienst Folgendes:
    • Den Bearertoken (ein JSON-Web-Token) im Header der HTTP-POST-Anforderung prüfen. Überprüfung kann auch durch die Nutzung von Beispielbibliotheken erfolgen, die von Microsoft bereitgestellt werden.
    • Token für begrenzte Zwecke von Ihrem Dienst als Teil der Ziel-URL verwenden, welche von Ihrem Dienst zum Korrelieren der Dienst-URL mit der beabsichtigten Anforderung und dem Benutzer verwendet werden kann. Dies ist optional, wird jedoch dringend empfohlen.

Bearertoken

Alle Aktionsanforderungen von Microsoft verfügen über ein Bearertoken im HTTP-Authorization-Header. Dieses Token ist ein von Microsoft signiertes JSON-Web-Token (JWT), das wichtige Ansprüche enthält, die dringend von dem Dienst zu überprüfen sind, der die entsprechende Anforderung verarbeitet.

Anspruchsname Wert
aud Die Basis-URL des Zieldiensts, z. B.https://www.api.contoso.com
sub Die Identität des Benutzers, der die Aktion ausgeführt hat. Für per E-Mail gesendete Nachrichten mit Aktionen wäre sub die E-Mail-Adresse des Benutzers. Für Connectors wäre sub objectID des Benutzers, der die Aktion ausgeführt hat.
sender Die Identität der Absender der Nachricht mit der Aktion.

In der Regel führt ein Dienst die folgenden Überprüfungen durch.

  1. Das Token ist von Microsoft signiert.
  2. Der aud-Anspruch entspricht der Basis-URL des Diensts.

Für alle oben genannten Überprüfungen kann der Dienst den sender- und sub-Anforderungen vertrauen, dass sie die Identität des Absenders und des Benutzers sind, die die Aktionen ausführen. Ein Dienst kann optional prüfen, ob die sender- und sub-Ansprüche mit dem erwarteten Sender und Benutzer übereinstimmen.

Informationen zu den Überprüfungen des JWT-Tokens finden Sie in den Microsoft-Codebeispielen weiter unten.

Token für begrenzte Zwecke

Token für begrenzte Zwecke können zum Korrelieren von Dienst-URLs mit bestimmten Nachrichten und Benutzern verwendet werden. Microsoft empfiehlt Dienstanbietern die Verwendung von Token für begrenzte Zwecke im Rahmen der Aktionsziel-URL oder im Text der Anforderung, die vom Dienst zurückkommt. Beispiel:

https://contoso.com/approve?requestId=abc&limitedPurposeToken=a1b2c3d4e5...

Token für begrenzte Zwecke dienen als Korrelations-IDs (z. B. für Hash-Token unter Verwendung von userID, requestID und salt). Dies ermöglicht dem Dienstanbieter das Nachverfolgen von Aktions-URLs, die generiert werden, und das Senden von Diesen gemäß den Aktionsanforderungen, die empfangen werden. Neben Korrelation kann der Dienstanbieter das Token für begrenzte Zwecke zum Schutz vor Replay-Angriffen verwenden. Beispielsweise kann der Dienstanbieter die Anforderung ablehnen, wenn die Aktion bereits mit demselben Token durchgeführt wurde.

Microsoft schreibt nicht vor, wie Token für begrenzte Zwecke zu entwerfen oder vom Dienst zu verwenden sind. Dieses Token ist für Microsoft nicht transparent und wird einfach an den Dienst zurückgesendet.