Remise d’événements WebHook

Un Webhook constitue l’un des nombreux moyens de recevoir des événements provenant d’Azure Event Grid. Lorsqu'un nouvel événement est prêt, le service Event Grid POST une requête HTTP au point de terminaison configuré avec les informations d'événement dans le corps de la requête.

Comme de nombreux autres services qui prennent en charge les Webhooks, Event Grid vous demande de prouver que vous êtes propriétaire de votre point de terminaison Webhook avant de démarrer la diffusion d'événements vers ce point de terminaison. Cette condition empêche tout utilisateur malveillant d'inonder votre point de terminaison d'événements.

Validation de point de terminaison avec des événements Event Grid

Quand vous utilisez un des trois services Azure suivants, l’infrastructure Azure gère automatiquement cette validation :

• Azure Logic Apps avec connecteur Event Grid
• Azure Automation via webhook
• Azure Functions avec déclencheur Event Grid

Si vous utilisez un autre type de point de terminaison, comme une fonction Azure basée sur un déclencheur HTTP, le code de votre point de terminaison doit participer à l'établissement d'une liaison de validation avec EventGrid. Event Grid prend en charge deux méthodes de validation de l'abonnement.

• Établissement d'une liaison synchrone : Au moment de la création de l'abonnement aux événements, Event Grid envoie un événement de validation d'abonnement à votre point de terminaison. Le schéma de cet événement est semblable à celui de n'importe quel autre événement Event Grid. La partie données de cet événement inclut une propriété validationCode. Votre application vérifie que la requête de validation concerne un abonnement à un événement attendu, et renvoie le code de validation dans la réponse de manière synchrone. Ce mécanisme d'établissement de liaison est pris en charge dans toutes les versions d'Event Grid.

• Établissement d'une liaison asynchrone : Dans certains cas, il est impossible de renvoyer le validationCode de manière synchrone. Par exemple, si vous utilisez un service tiers (comme Zapier ou IFTTT), vous ne pouvez pas envoyer le code de validation par programmation.

  Event Grid prend en charge l'établissement d'une liaison de validation manuel. Si vous créez un abonnement aux événements à l'aide d'un kit de développement logiciel (SDK) ou d'un outil qui utilise l'API 2018-05-01-preview ou version ultérieure, Event Grid envoie une propriété validationUrl dans la partie données de l'événement de validation de l'abonnement. Pour terminer l'établissement de la liaison, recherchez cette URL dans les données d'événement et envoyez-lui une requête GET. Vous pouvez utiliser un client REST ou votre navigateur web.

  L’URL fournie est valable pendant 10 minutes. Pendant ce temps, l’état d’approvisionnement de l’abonnement aux événements est AwaitingManualAction. Si vous n’effectuez pas la validation manuelle dans les 10 minutes, l’état d’approvisionnement est défini sur Failed. Vous devez recréer l’abonnement aux événements avant de commencer la validation manuelle.

  Ce mécanisme d’authentification requiert également que le point de terminaison webhook retourne un code d’état HTTP 200 afin qu’il sache que le POST pour l’événement de validation a été accepté avant qu’il ne puisse être placé dans le mode de validation manuelle. En d'autres termes, si le point de terminaison renvoie un code 200 mais ne renvoie pas de réponse de validation de manière synchrone, le mode est transmis au mode de validation manuelle. S’il y a une opération GET sur l’URL de validation dans les 10 minutes, l’établissement d’une liaison de validation est considéré comme réussi.

Remarque

L’utilisation de certificats auto-signés pour la validation n’est pas prise en charge. Utilisez plutôt un certificat signé auprès d’une autorité de certification commerciale (AC).

Détails de validation

• Au moment de la création/mise à jour de l'abonnement aux événements, Event Grid publie un événement de validation d'abonnement sur le point de terminaison cible.
• L’événement contient une valeur d’en-tête aeg-event-type: SubscriptionValidation.
• Le corps de l’événement dispose du même schéma que les autres événements Event Grid.
• La propriété eventType de l’événement est Microsoft.EventGrid.SubscriptionValidationEvent.
• La propriété data de l’événement inclut une propriété validationCode avec une chaîne générée de façon aléatoire. Par exemple : validationCode: acb13….
• Les données d’événement incluent une propriété validationUrl avec une URL pour la validation manuelle de l’abonnement.
• Le tableau contient uniquement l’événement de validation. Les autres événements sont envoyés dans une requête distincte, une fois que vous avez renvoyé le code de validation.
• Les SDK de plan de données EventGrid ont des classes correspondant aux données des événements de validation d’abonnement et à la réponse de validation d’abonnement.

Un exemple de SubscriptionValidationEvent est illustré ci-dessous :

[
  {
    "id": "2d1781af-3a4c-4d7c-bd0c-e34b19da4e66",
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "subject": "",
    "data": {
      "validationCode": "512d38b6-c7b8-40c8-89fe-f46f9e9622b6",
      "validationUrl": "https://rp-eastus2.eventgrid.azure.net:553/eventsubscriptions/myeventsub/validate?id=0000000000-0000-0000-0000-00000000000000&t=2022-10-28T04:23:35.1981776Z&apiVersion=2018-05-01-preview&token=1A1A1A1A"
    },
    "eventType": "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime": "2022-10-28T04:23:35.1981776Z",
    "metadataVersion": "1",
    "dataVersion": "1"
  }
]

Pour prouver que vous êtes propriétaire du point de terminaison, renvoyez le code de validation dans la propriété validationResponse, comme indiqué dans l’exemple suivant :

{
  "validationResponse": "512d38b6-c7b8-40c8-89fe-f46f9e9622b6"
}

Effectuez ensuite l'une des étapes suivantes :

• Vous devez retourner un code d’état de réponse HTTP 200 OK. HTTP 202 Accepté n’est pas considéré comme une réponse de validation d’abonnement Event Grid valide. La requête HTTP doit s’achever dans un délai de 30 secondes. Si l’opération ne se termine pas dans les 30 secondes, elle est annulée et pourra faire l’objet d’une nouvelle tentative au bout de 5 secondes. Si toutes les tentatives échouent, cela est traité comme une erreur de validation d’établissement d’une liaison.

  Le fait que votre application soit prête à gérer et retourner le code de validation indique que vous avez créé l’abonnement à l’événement et que vous êtes censé recevoir l’événement. Imaginez le scénario dans lequel aucune validation de poignée d’établissement d’une liaison de main n'est prise en charge et qu'un pirate informatique apprend à connaître l'URL de votre application. Le pirate peut créer une rubrique et un abonnement aux événements avec l’URL de votre application, et commencer à mener une attaque DoS à votre application en envoyant un grand nombre d’événements. La validation de négociation empêche cela.

  Imaginez que la validation est déjà implémentée dans votre appli, car vous avez créé vos propres abonnements aux événements. Même si un pirate informatique crée un souscription à un événement avec l'URL de votre application, votre implémentation correcte de l'événement de requête de validation vérifie l'en-tête aeg-subscription-name de la requête pour garantir qu'il s'agit d'une souscription à un événement que vous reconnaissez.

  Même après cette implémentation de négociation correcte, un pirate peut inonder votre application (elle a déjà validé l’abonnement aux événements) en répliquant une demande qui semble provenir d’Event Grid. Pour éviter cela, vous devez sécuriser votre webhook avec l'authentification Microsoft Entra. Pour plus d’informations, consultez Diffusion d’événements vers des points de terminaison protégés par Microsoft Entra.

• Sinon, vous pouvez valider manuellement l’abonnement en envoyant une demande GET à l’URL de validation. L’abonnement aux événements reste dans un état d’attente jusqu’à ce qu’il soit validé. L’URL de validation utilise le port 553. Si vos règles de pare-feu bloquent le port 553, vous devez mettre à jour les règles pour une négociation manuelle réussie d’établissement d’une liaison.

  Lors de votre validation de l'événement de validation d'abonnement, si vous identifiez qu'il ne s'agit pas d'un abonnement à un événement pour lequel vous attendez des événements, vous ne renverrez pas de réponse 200 ou aucune réponse du tout. Par conséquent, la validation échoue.

Pour accéder à un exemple de gestion d'établissement de liaison de validation d'abonnement, consultez un exemple C#.

Validation de point de terminaison avec CloudEvents v1.0

CloudEvents v1.0 implémente sa propre sémantique de protection contre les abus en utilisant la méthode HTTP OPTIONS. Pour plus d'informations à ce sujet, cliquez ici. Lorsque vous utilisez le schéma CloudEvents pour la sortie, Event Grid l’utilise avec la protection contre les abus CloudEvents v1.0 à la place du mécanisme d’événement de validation Event Grid.

Compatibilité du schéma d’événement

Quand une rubrique est créée, un schéma d’événement entrant est défini. Et quand un abonnement est créé, un schéma d’événement sortant est défini. Le tableau suivant vous montre la compatibilité autorisée lors de la création d’un abonnement.

Schéma d’événement entrant	Schéma d’événement sortant	Pris en charge
Schéma Event Grid	Schéma Event Grid	Yes
	Schéma d’événements cloud v1.0	Yes
	Schéma d’entrée personnalisé	No
Schéma d’événements cloud v1.0	Schéma Event Grid	No
	Schéma d’événements cloud v1.0	Yes
	Schéma d’entrée personnalisé	No
Schéma d’entrée personnalisé	Schéma Event Grid	Yes
	Schéma d’événements cloud v1.0	Yes
	Schéma d’entrée personnalisé	Oui

Étapes suivantes

Consultez l’article suivant pour savoir comment dépanner les validations d’abonnement aux événements : Dépanner les validations d’abonnement aux événements.