Sicherheitsanforderungen für Nachrichten mit Aktionen in Office 365Security requirements for actionable messages 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:Securing actionable email is simple and easy. There are two phases within the end-to-end experience that impose security requirements on your service when supporting actionable messages with Office 365. The phases and their corresponding requirements are as follows.

  1. Sendephase: Es gelten folgende Voraussetzungen für Ihren Dienst, um Nachrichten mit Aktionen zu senden:Send phase: The pre-requisites for your service to send actionable messages are as follows:
    • 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.If you're using actionable email, check that your mail servers are leveraging SPF and DKIM as an additional safeguard against sender email spoofing (majority of mail systems do that already). Note that this does not apply to connector messages.
    • Der Dienst muss bei Microsoft registriert sein.Your service must be registered with Microsoft.
    • Die Aktions-URL muss HTTPS unterstützen.The Action URL must support HTTPS.
  2. Phase der Aktionsverarbeitung: Wenn Sie eine Aktion verarbeiten, sollte Ihr Dienst Folgendes:Action processing phase: When processing an action, your service should:
    • 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.Verify the bearer token (a JSON Web token) included in the header of the HTTP POST request. Verification can also be done leveraging the sample libraries provided by Microsoft.
    • 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.Include Limited Purpose Token from your service as part of the target URL, which can be used by your service to correlate the service URL with the intended request & user. This is optional, but highly recommended.

BearertokenBearer Token

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.All action requests from Microsoft have a bearer token in the HTTP Authorization header. This token is a JSON Web Token (JWT) token signed by Microsoft, and it includes important claims that we strongly recommend should be verified by the service handling the associated request.

AnspruchsnameClaim name WertValue
aud Die Basis-URL des Zieldiensts, z. B.https://api.contoso.comThe base URL of the target service, e.g. https://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.The identity of the user who took the action. For Actionable Messages sent over email, sub would be the email address of the user. For connectors, sub will be the objectID of the user who took the action.
sender Die Identität der Absender der Nachricht mit der Aktion.The identity of sender of the message containing the action.

In der Regel führt ein Dienst die folgenden Überprüfungen durch.Typically, a service will perform the following verifications.

  1. Das Token ist von Microsoft signiert.The token is signed by Microsoft.
  2. Der aud-Anspruch entspricht der Basis-URL des Diensts.The aud claim corresponds to the service's base URL.

Anhand aller oben genannten Überprüfungen kann der Dienst darauf vertrauen, dass die sender- und sub-Ansprüche der Identität des Senders und des agierenden Benutzers entsprechen. Der Dienst kann überprüfen, dass die sender- und sub-Ansprüche mit dem erwarteten Sender und Benutzer übereinstimmen.With all the above verifications done, the service can trust the sender and sub claims to be the identity of the sender and the user taking the action. The service can validate that the sender and sub claims match the sender and user it is expecting.

Informationen zu den Überprüfungen des JWT-Tokens finden Sie in den Microsoft-Codebeispielen weiter unten.Please refer to the Microsoft code samples provided below, which show how to do these validations on the JWT token.

Action-Authorization-HeaderAction-Authorization header

Die Verwendung des Authorization-Headers durch Aktion erfordernde Nachrichten kann zu Konflikten mit vorhandenen Authentifizierungs-/Autorisierungsmechanismen für den Zielendpunkt führen.The use of Authorization header by Actionable messages may interfere with existing authentication/authorization mechanism for the target endpoint. In diesem Fall können Entwickler den Authorization-Header null oder eine leere Zeichenfolge in der headers-Eigenschaft einer Action.Http-Aktion festlegen.In this case, developers can set the Authorization header to null or an empty string in the headers property of an Action.Http action. Aktion erfordernde Nachrichten senden dasselbe Bearertoken über den Action-Authorization-Header, statt den Authorization-Header dazu zu verwenden.Actionable messages will then send the same bearer token via Action-Authorization header instead of using Authorization header.

Tipp

Der Azure Logic App-Dienst gibt HTTP 401 Unauthorized zurück, wenn der Authorization-Header das von Aktion erfordernden Nachrichten festgelegte Bearertoken enthält.The Azure Logic App service returns HTTP 401 Unauthorized if the Authorization header contains the bearer token set by actionable messages.

Beispiel für Action.Http mit Action-Authorization-HeaderExample Action.Http with Action-Authorization header

{
  "type": "Action.Http",
  "title": "Say hello",
  "method": "POST",
  "url": "https://api.contoso.com/sayhello",
  "body": "{{nameInput.value}}",
  "headers": [
    { "name": "Authorization", "value": "" }
  ]
}

Token für begrenzte ZweckeLimited-Purpose Tokens

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:Limited purpose tokens can be used to correlate service URLs with specific messages and users. Microsoft recommends that service providers use "limited-purpose tokens" as part of the action target URL, or in the body of the request coming back to the service. For example:

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.Limited-purpose tokens act as correlation IDs (for e.g. a hashed token using the userID, requestID, and salt). This allows the service provider to keep track of the action URLs it generates and sends out and match it with action requests coming in. In addition to correlation, the service provider may use the limited purpose token to protect itself from replay attacks. For example, the service provider may choose to reject the request, if the action was already performed previously with the same token.

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.Microsoft does not prescribe how the limited-access tokens should be designed or used by the service. This token is opaque to Microsoft, and is simply echoed back to the service.