Exigences de sécurité pour les messages appelant une action dans Office 365

Article
04/29/2024

Importante

L’intégration de nouveaux fournisseurs de messages actionnables avec une étendue globale est temporairement suspendue jusqu’au 30 juin 2024 en raison de mises à niveau du service. Les fournisseurs globaux existants et l’intégration des fournisseurs d’étendue d’organisation et de test ne sont pas affectés. Pour plus d’informations, consultez Forum aux questions sur les messages actionnables.

La sécurisation des e-mails appelant une action est très simple. Il existe deux phases au sein de l’expérience de bout en bout qui imposent des exigences de sécurité à votre service lors de la prise en charge de messages appelant une action avec Office 365. Les phases et leurs exigences respectives sont les suivantes :

Phase d’envoi : Les composants requis pour que votre service envoie des messages appelant une action sont les suivants :
- Si vous utilisez les messages actionnables, vous devez activer la vérification de l’expéditeur. Cela ne s’applique pas aux messages de connecteur.
- Votre service doit être inscrit auprès de Microsoft.
- L’URL d’action doit prendre en charge HTTPS.
Phase de traitement d’action : Lors du traitement d’une action, votre service doit :
- Vérifier le jeton du porteur (un jeton web JSON) inclus dans l’en-tête de la requête HTTP POST. La vérification peut également être réalisée à l’aide des exemples de bibliothèque fournis par Microsoft.
- Inclure un jeton limité provenant de votre service dans le cadre de l’URL cible, qui peut être utilisé par votre service pour faire correspondre l’URL de service avec la demande et l’utilisateur souhaités. Cela est facultatif, mais fortement recommandé.

Vérification de l’expéditeur

Office 365 requiert la vérification de l’expéditeur pour pouvoir activer les messages actionnables via e-mail. Vos messages actionnables doivent provenir de serveurs qui implémentent DKIM (DomainKeys Identified Mail) et SPF (Sender Policy Framework), ou vous devez implémenter des cartes signées.

DKIM et SPF sont suffisants pour certains scénarios, mais cette solution ne fonctionne pas dans certaines situations où les e-mails sont envoyés via un fournisseur externe car il se peut que les destinataires ne puissent pas utiliser pas la fonction de messages actionnables améliorée. Pour cette raison, nous vous recommandons de toujours implémenter des cartes signées qui fonctionnent dans tous les cas et sont fondamentalement plus sécurisées car elles ne dépendent pas des enregistrements DNS.

Implémentation de DKIM et SPF

DKIM et SPF sont des normes industrielles permettant de prouver l’identité d’un expéditeur lors de l’envoi d’e-mails via SMTP. De nombreuses entreprises implémentent déjà ces normes pour sécuriser les e-mails qu’elles envoient. Pour en savoir plus sur SPF ou DKIM et leur implémentation, reportez-vous à :

Charges utile de la carte signée

Les messages actionnables envoyés par e-mail prennent en charge une différente méthode de vérification : signature de la charge utile de la carte avec une clé RSA ou un certificat X509. Cette méthode est requise dans les scénarios suivants :

Échec de SPF/DKIM provoqué par les paramètres expéditeur ou par les services de sécurité personnalisés du client destinataire en aval des services Office 365.
Votre scénario relatif aux messages actionnables nécessite un envoi depuis plusieurs comptes de messagerie.

Pour utiliser des cartes signées, vous devez enregistrer votre clé publique dans le tableau de bord du développeur de courrier électronique, puis utiliser la clé privée correspondante pour signer la carte.

SignedCard

Les cartes de message actionnable signées sont disponibles lors de l’envoi par e-mail. Utilisez ce format pour inclure une carte signée dans le corps HTML d’un e-mail. Cette charge utile est sérialisée au format Microdata ajouté à la fin du corps HTML.

<section itemscope itemtype="http://schema.org/SignedAdaptiveCard">
    <meta itemprop="@context" content="http://schema.org/extensions" />
    <meta itemprop="@type" content="SignedAdaptiveCard" />
    <div itemprop="signedAdaptiveCard" style="mso-hide:all;display:none;max-height:0px;overflow:hidden;">[SignedCardPayload]</div>
</section>

Remarque : les partenaires qui préfèrent utiliser l’entité MessageCard héritée peuvent créer une entité SignedMessageCard à la place de l’entité SignedAdaptiveCard.

SignedCardPayload

SignedCardPayload est une chaîne codée JSON Web Signature (JWS). RFC7515 décrit JWS, et RFC7519 décrit JSON Web Token (JWT). Étant donné qu'aucun claim n'est requis dans JWT, les bibliothèques JWT peuvent être utilisées pour construire la signature JWS.

Remarque : le terme « JWT » peut être utilisé de manière interchangeable dans la pratique. Toutefois, nous préférons ici utiliser le terme « JWS ».

Voici un exemple de SignedCardPayload. La carte adaptative encodée s’affiche sous le format [en-tête].[charge utile].[signature] en respectant les spécifications JWS.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZW5kZXIiOiJzZXJ2aWNlLWFjY291bnRAY29udG9zby5jb20iLCJvcmlnaW5hdG9yIjoiNjVjNjgwZWYtMzZhNi00YTFiLWI4NGMtYTdiNWM2MTk4NzkyIiwicmVjaXBpZW50c1NlcmlhbGl6ZWQiOiJbXCJqb2huQGNvbnRvc28uY29tXCIsXCJqYW5lQGNvbnRvc28uY29tXCJdIiwiYWRhcHRpdmVDYXJkU2VyaWFsaXplZCI6IntcIiRzY2hlbWFcIjpcImh0dHA6Ly9hZGFwdGl2ZWNhcmRzLmlvL3NjaGVtYXMvYWRhcHRpdmUtY2FyZC5qc29uXCIsXCJ0eXBlXCI6XCJBZGFwdGl2ZUNhcmRcIixcInZlcnNpb25cIjpcIjEuMFwiLFwiYm9keVwiOlt7XCJzaXplXCI6XCJsYXJnZVwiLFwidGV4dFwiOlwiSGVsbG8gQWN0aW9uYWJsZSBtZXNzYWdlXCIsXCJ3cmFwXCI6dHJ1ZSxcInR5cGVcIjpcIlRleHRCbG9ja1wifV0sXCJhY3Rpb25zXCI6W3tcInR5cGVcIjpcIkFjdGlvbi5JbnZva2VBZGRJbkNvbW1hbmRcIixcInRpdGxlXCI6XCJPcGVuIEFjdGlvbmFibGUgTWVzc2FnZXMgRGVidWdnZXJcIixcImFkZEluSWRcIjpcIjNkMTQwOGY2LWFmYjMtNGJhZi1hYWNkLTU1Y2Q4NjdiYjBmYVwiLFwiZGVza3RvcENvbW1hbmRJZFwiOlwiYW1EZWJ1Z2dlck9wZW5QYW5lQnV0dG9uXCJ9XX0iLCJpYXQiOjE1NDUzNDgxNTN9.BP9mK33S1VZyjtWZd-lNTTjvueyeeoitygw9bl17TeQFTUDh9Kg5cB3fB7BeZYQs6IiWa1VGRdiiR4q9EkAB1qDsmIcJnw6aYwDUZ1KY4lNoYgQCH__FxEPHViGidNGtq1vAC6ODw0oIfaTUWTa5cF5MfiRBIhpQ530mbRNnA0QSrBYtyB54EDJxjBF1vNSKOeVHAl2d4gqcGxsytQA0PA7XMbrZ8B7fEU2uNjSiLQpoh6A1tevpla2C7W6h-Wekgsmjpw2YToAOX67VZ1TcS5oZAHmjv2RhqsfX5DlN-ZsTRErU4Hs5d92NY9ijJPDunSLyUFNCw7HLNPFqqPmZsw

L’en-tête dans le code JWS ci-dessus est :

{
  "alg": "RS256",
  "typ": "JWT"
}

La charge utile dans le code JWS ci-dessus est :

{
  "sender": "service-account@contoso.com",
  "originator": "65c680ef-36a6-4a1b-b84c-a7b5c6198792",
  "recipientsSerialized": "[\"john@contoso.com\",\"jane@contoso.com\"]",
  "adaptiveCardSerialized": "{\"$schema\":\"http://adaptivecards.io/schemas/adaptive-card.json\",\"type\":\"AdaptiveCard\",\"version\":\"1.0\",\"body\":[{\"size\":\"large\",\"text\":\"Hello Actionable message\",\"wrap\":true,\"type\":\"TextBlock\"}],\"actions\":[{\"type\":\"Action.InvokeAddInCommand\",\"title\":\"Open Actionable Messages Debugger\",\"addInId\":\"3d1408f6-afb3-4baf-aacd-55cd867bb0fa\",\"desktopCommandId\":\"amDebuggerOpenPaneButton\"}]}",
  "iat": 1545348153
}

Claims requis

Claim	Description
`originator`	DOIT être défini sur l’ID fourni par Microsoft pendant l’intégration.
`iat`	Heure de signature de la charge utile.
`sender`	Adresse e-mail utilisée pour envoyer ce message actionnable.
`recipientsSerialized`	Liste stringified des destinataires du message électronique. Cela doit inclure tous les destinataires (À/CC) du message.
`adaptiveCardSerialized`	Carte adaptative stringified.

Exemple de code générant une carte signée :

Vérification que les demandes proviennent de Microsoft

Toutes les demandes d’action de Microsoft comportent un jeton du porteur dans l’en-tête Authorization HTTP. Il s’agit d’un jeton web JSON (JWT) signé par Microsoft qui inclut des revendications importantes, qu’il est vivement recommandé de faire vérifier par le service gérant la demande associée.

Nom de la revendication	Valeur
`aud`	URL de base du service cible, par exemple, `https://api.contoso.com`.
`iss`	L’émetteur du jeton. Cette situation doit être `https://substrate.office.com/sts/`
`sub`	Identité de l’utilisateur ayant effectué l’action. Pour les messages appelant une action envoyés par courrier électronique, `sub` correspondrait à l’adresse e-mail de l’utilisateur. Pour les connecteurs, `sub` correspond à l’ID d’objet de l’utilisateur ayant effectué l’action.
`sender`	Identité de l’expéditeur du message contenant l’action. Cette valeur n'est présente que si le message actionnable a été envoyé par e-mail. Les messages actionnables envoyés via des connecteurs n’incluent pas cette réclamation dans leur jeton du porteur.

En règle générale, un service effectue les vérifications suivantes.

Le jeton est signé par Microsoft. Les métadonnées OpenID se trouvent sur https://substrate.office.com/sts/common/.well-known/openid-configuration, qui inclut des informations sur les clés de signature.
La revendication aud correspond à l’URL de base du service.

Une fois tous les éléments ci-dessus vérifiés, le service peut approuver les revendications sender et sub en tant qu’identité de l’expéditeur et de l’utilisateur réalisant l’action. Le service peut vérifier que les sender revendications et correspondent sub à l’expéditeur et à l’utilisateur attendus.

Reportez-vous aux exemples de code Microsoft fournis ci-dessous, qui montrent comment effectuer ces validations sur le jeton JWT.

En-tête Action-Authorization

L’utilisation de l’en-tête Authorization par les messages actionnables peut interférer avec le mécanisme d’authentification/autorisation existant pour le point de terminaison cible. Dans ce cas, les développeurs peuvent définir l’en-tête Authorization sur une chaîne vide dans la headers propriété d’une Action.Http action. Les messages actionnables enverront alors le même jeton du porteur via l’en-tête Action-Authorization au lieu d’utiliser l’en-tête Authorization.

Conseil

Le service Azure Logic App renvoie HTTP 401 Unauthorized si l’en-tête Authorization contient le jeton du porteur défini par les messages actionnables.

Exemple d’en-tête Action.Http avec Action-Authorization

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

Vérification de l’identité de l’utilisateur

Le jeton du porteur inclus avec toutes les demandes inclut l’identité Azure AD de l’utilisateur d’Office 365 qui a entreprise l’action. Si nécessaire, vous pouvez inclure votre propre jeton, propre à votre service, dans les URL de vos actions HTTP pour représenter l’identité de l’utilisateur dans votre système. Microsoft n’impose pas la façon dont les jetons limités doivent être conçus ou utilisés par le service. Ce jeton est opaque pour Microsoft, et est simplement renvoyé au service.

Les jetons spécifiques au service peuvent permettre de corréler les URL de service avec des utilisateurs et des messages spécifiques. Si vous utilisez votre propre jeton spécifique au service, Microsoft recommande de l’inclure dans le cadre de l’URL cible d’action ou dans le corps de la demande renvoyée au service. Par exemple :

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

Les jetons spécifiques au service agissent en tant qu’ID de corrélation (par exemple, un jeton haché utilisant l’ID utilisateur, l’ID de demande et salt). Cela permet au fournisseur de services d’effectuer le suivi des URL d’action qu’il génère et envoie, et de les mettre en correspondance avec les demandes d’action entrantes. En plus de la corrélation, le fournisseur de services peut utiliser le jeton spécifique au service pour se protéger contre les attaques de relecture. Par exemple, le fournisseur de services peut choisir de refuser la demande, si l’action a déjà été effectuée précédemment avec le même jeton.