Authentifier les demandes de Azure Batch

  • Article

Chaque demande adressée au service Batch doit être authentifiée. Le service Batch prend en charge l’authentification via une clé partagée ou Microsoft Entra ID.

Authentification via une clé partagée

Une demande authentifiée nécessite deux en-têtes : l’en-tête Date ou ocp-date et l’en-têteAuthorization . Les sections suivantes décrivent comment construire ces en-têtes.

Spécification de l'en-tête de date

Toutes les demandes authentifiées doivent inclure un horodatage UTC pour la demande. Vous pouvez spécifier l’horodatage dans l’en-tête ocp-date ou dans l’en-tête de date HTTP/HTTPS standard. Si les deux en-têtes sont spécifiés pour la requête, la valeur de ocp-date est utilisée comme heure de création de la demande.

Le service Batch doit recevoir une demande dans les 15 minutes suivant sa création. Ce faisant, le service est protégé contre les attaques de sécurité, telles que les attaques par relecture. L’en-tête ocp-date est fourni, car certains proxies et bibliothèques clientes HTTP définissent automatiquement l’en-tête Date et ne vous donnent pas la possibilité de lire sa valeur pour l’inclure dans la demande authentifiée. Si vous définissez ocp-date, construisez la signature avec une valeur vide pour l’en-tête Date .

Spécification de l'en-tête d'autorisation

Une demande authentifiée doit inclure l’en-tête d’autorisation . Pour authentifier une demande, vous devez signer la demande avec la clé du compte qui effectue la demande et passer cette signature dans le cadre de la demande.

Le format de l’en-tête Authorization est le suivant :

Authorization="SharedKey <AccountName>:<Signature>"

SharedKey est le nom du schéma d'autorisation, AccountName est le nom du compte demandant la ressource et Signature est le HMAC (Hash-based Message Authentication Code) construit à partir de la demande et calculé en utilisant l'algorithme SHA256, puis encodé en Base64.

Les sections suivantes décrivent comment construire l’en-tête d’autorisation .

Construction de la chaîne de signature

Lors de la construction de la chaîne de signature, n'oubliez pas les points suivants :

  • La partie VERB de la chaîne est le verbe HTTP, par exemple GET ou POST, et doit être en majuscule.

  • Chaque en-tête inclus dans la chaîne de signature ne peut apparaître qu'une seule fois.

  • Les valeurs de tous les en-têtes standard HTTP doivent être incluses dans la chaîne dans l'ordre indiqué dans le format de signature, sans les noms d'en-tête. Ces en-têtes peuvent être vides s'ils ne sont pas spécifiés dans le cadre de la demande ; dans ce cas, seul le caractère de nouvelle ligne est nécessaire.

  • Lorsque le verbe est POST, les valeurs de Content-Type et Content-Length sont requises en tant qu'en-têtes de demande et valeurs dans la chaîne de signature. Content-Type doit être défini sur application/json ; odata=minimalmetadata.

  • Si l’en-tête ocp-date est spécifié, l’en-tête Date n’est pas obligatoire, spécifiez simplement une ligne vide pour la partie Date de la chaîne de signature. Dans ce cas, suivez les instructions de la section Construire la chaîne d’en-têtes canoniques pour ajouter l’en-tête ocp-date .

  • Tous les caractères de nouvelle ligne (\n) affichés sont nécessaires dans la chaîne de signature.

  • Pour plus d'informations sur la construction des chaînes CanonicalizedHeaders et CanonicalizedResource qui composent une partie de la chaîne de signature, consultez les sections appropriées plus loin dans cette rubrique.

Pour encoder la chaîne de signature pour une demande effectuée auprès du service Batch, utilisez le format suivant :

  
StringToSign = VERB + "\n" +  
  Content-Encoding + "\n"  
  Content-Language + "\n"  
  Content-Length + "\n"  
  Content-MD5 + "\n"  
  Content-Type + "\n" +  
  Date + "\n" +  
  If-Modified-Since + "\n"  
  If-Match + "\n"  
  If-None-Match + "\n"  
  If-Unmodified-Since + "\n"  
  Range + "\n"  
  CanonicalizedHeaders +   
  CanonicalizedResource;

L’exemple suivant montre une chaîne de signature pour une demande de liste des travaux dans un compte avec un délai d’expiration de 20 secondes. Lorsqu'aucune valeur d'en-tête n'existe, seul le caractère de nouvelle ligne est spécifié.

GET\n\n\n\n\n\n\n\n\n\n\n\nocp-date:Tue, 29 Jul 2014 21:49:13 GMT\n /myaccount/jobs\napi-version:2014-01-01.1.0\ntimeout:20

La décomposition ligne par ligne montre chaque portion de la même chaîne :

  
GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length*/  
\n    /*Content-MD5*/  
\n    /*Content-Type*/  
\n    /*Date*/  
\n    /*If-Modified-Since */  
\n    /*If-Match */  
\n    /*If-None-Match */  
\n    /*If-Unmodified-Since*/  
\n    /* Range */  
ocp-date:Tue, 29 Jul 2014 21:49:13 GMT\n    /*CanonicalizedHeaders*/  
/myaccount/jobs\napi-version:2014-04-01.1.0\ntimeout:20    /*CanonicalizedResource*/

Ensuite, encodez cette chaîne à l’aide de l’algorithme HMAC-SHA256 sur la chaîne de signature encodée en UTF-8, construisez l’en-tête Authorization et ajoutez l’en-tête à la requête. L’exemple suivant montre l’en-tête Authorization pour la même opération :

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Construction de la chaîne d'en-têtes au format canonique

Pour construire la partie CanonicalizedHeaders de la chaîne de signature, procédez comme suit :

  1. Récupérez tous les en-têtes de la ressource qui commencent par ocp-, y compris l’en-tête ocp-date .

  2. Convertissez chaque nom d'en-tête HTTP en minuscule.

  3. Triez les en-têtes de façon lexicographique par nom d'en-tête, en ordre croissant. Chaque en-tête ne peut s'afficher qu'une seule fois dans la chaîne.

  4. Remplacez les espaces blancs par un seul espace.

  5. Supprimez tous les espaces blancs autour des deux-points dans l'en-tête.

  6. Ajoutez un caractère de nouvelle ligne à chaque en-tête au format canonique dans la liste résultante. Construisez la chaîne CanonicalizedHeaders en concaténant tous les en-têtes de cette liste en une chaîne unique.

Construction de la chaîne de ressource au format canonique

La partie CanonicalizedResource de la chaîne de signature représente la ressource du service Batch visée par la demande. N'importe quelle partie de la chaîne CanonicalizedResource qui est dérivée de l'URI de la ressource doit être encodée exactement comme dans l'URI.

Gardez à l'esprit les règles suivantes pour construire la chaîne de ressource rendue canonique :

  • Évitez d'utiliser le caractère de nouvelle ligne (\n) dans les valeurs pour les paramètres de requête. S'il doit être utilisé, vérifiez qu'il n'affecte pas le format de la chaîne de ressource rendue canonique.

  • Évitez d'utiliser des virgules dans les valeurs de paramètre de requête.

Vous pouvez construire la chaîne CanonicalizedResource comme suit :

  1. Commencez par une barre oblique (« / »), suivie du nom du compte qui possède la ressource à laquelle vous accédez.

  2. Ajoutez le chemin URI encodé de la ressource, sans aucun paramètre de requête.

  3. Récupérez tous les paramètres de requête sur l’URI de ressource, y compris le paramètre api-version .

  4. Convertissez tous les noms de paramètre en minuscule.

  5. Triez les paramètres de requête de façon lexicographique par nom de paramètre, en ordre croissant.

  6. Décodez par URL chaque nom et valeur de paramètre de requête.

  7. Ajoutez chaque nom et valeur de paramètre de requête à la chaîne dans le format suivant, en veillant à inclure les deux-points (:) entre le nom et la valeur :

    parameter-name:parameter-value

  8. Si un paramètre de requête a plusieurs valeurs, triez toutes les valeurs par ordre lexicographique, puis incluez-les dans une liste séparée par des virgules :

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

  9. Ajoutez un caractère de nouvelle ligne (\n) après chaque paire nom-valeur.

Encodage de la signature

Pour encoder la signature, appelez l'algorithme HMAC-SHA256 dans la chaîne de signature encodée en UTF-8 et encodez le résultat en Base64. Utilisez le format suivant (affiché comme pseudocode) :

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

Authentification via Microsoft Entra ID

Azure Batch prend en charge l’authentification avec Microsoft Entra ID, le service de gestion des annuaires et des identités basé sur le cloud multilocataire de Microsoft. Azure utilise Microsoft Entra ID pour authentifier ses propres clients, administrateurs de services et utilisateurs de l’organisation.

Notes

L’authentification avec Microsoft Entra ID est facultative, mais recommandée. Elle est requise uniquement si votre compte Batch est configuré pour allouer des pools dans un abonnement utilisateur. L’option d’allocation de pool est disponible lorsque vous créez un compte Batch. Si votre compte est configuré pour allouer des pools dans un abonnement géré par Batch, l’utilisation de Microsoft Entra ID pour l’authentification est facultative. Pour plus d’informations, consultez Batch – Prise en charge des réseaux virtuels et des images personnalisées pour les pools de machines virtuelles.

Pour obtenir des informations générales sur l’authentification d’une demande auprès d’Azure AD, consultez Référence de l’API REST Azure. Pour utiliser Azure AD avec le service Batch, vous avez besoin des points de terminaison suivants.

Le point de terminaison « commun » du point de terminaison Azure AD est le suivant :

https://login.microsoftonline.com/common

Le point de terminaison de ressource pour le service Batch est :

https://batch.core.windows.net/

Pour plus d’informations sur l’inscription de votre application Batch auprès de Microsoft Entra ID, consultez Authentifier Azure Batch services avec Microsoft Entra ID.