Cet article a fait l’objet d’une traduction automatique. Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez également afficher le texte anglais dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte traduit.
Traduction
Anglais

Authentification pour les services Azure Storage

 

Chaque demande adressée à un service de stockage doit être authentifiée, sauf si la demande est pour une ressource d'objet blob ou de conteneur qui a été rendue disponible pour un accès public ou signé.

System_CAPS_importantImportant

Les services de stockage Microsoft Azure prennent en charge les protocoles HTTP et HTTPS. Toutefois, nous vous conseillons d'utiliser le protocole HTTPS.

Les services BLOB, File d'attente, Table et Fichier prennent en charge les schémas d'authentification Shared Key, dans les versions 2009-09-19 et ultérieures (pour les services BLOB, File d'attente et Table), et dans les versions 2014-02-14 et ultérieures (pour le service File) :

  • Shared Key pour les services BLOB, de File d'attente et de Fichier. Utiliser le schéma d'authentification Shared Key pour effectuer des demandes aux services Blob, file d'attente et de fichier. L'authentification Shared Key dans les versions 2009-09-19 et ultérieures prend en charge une chaîne de signature augmentée pour une sécurité renforcée, et exige que vous mettiez à jour votre service pour l'authentification à l'aide de cette signature augmentée.

  • Shared Key pour le service de Table. Utilisez le schéma d'authentification Shared Key pour effectuer des demandes aux services de Table à l'aide de l'API REST. L'authentification Shared Key pour le service Table dans les versions 2009-09-19 et ultérieures utilise la même chaîne de signature que dans les versions précédentes du service Table.

  • Shared Key Lite. Utilisez le schéma d'authentification Shared Key Lite pour effectuer des demandes aux services Blob, file d'attente, Table et fichier.

    Pour les versions 2009-09-19 et ultérieures des services BLOB et File d'attente, l'authentification Shared Key Lite prend en charge l'utilisation d'une chaîne de signature identique à celle prise en charge pour l'authentification Shared Key dans les versions antérieures des services BLOB et File d'attente. Vous pouvez donc utiliser Shared Key Lite pour effectuer des demandes auprès des services BLOB et de File d'attente sans mettre à jour votre chaîne de signature.

Une demande authentifiée requiert deux en-têtes : le Date ou x-ms-date en-tête et Authorization en-tête. Les sections suivantes décrivent comment construire ces en-têtes.

System_CAPS_noteRemarque

Vous pouvez rendre disponible un conteneur ou un objet blob pour l'accès public en définissant les autorisations d'un conteneur. Pour plus d'informations, consultez gérer l'accès aux ressources de stockage Azure. Vous pouvez rendre disponible un conteneur, un objet blob, une file d'attente ou une table pour l'accès signé via une signature d'accès partagé. Une signature d'accès partagé est authentifiée via un autre mécanisme. Consultez Délégation de l'accès avec une Signature d'accès partagé Pour plus de détails.

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

Les services de stockage vérifient qu'une demande n'a pas plus de 15 minutes avant qu'elle n'atteigne le service. Cela protège contre certaines attaques de sécurité, notamment les attaques par relecture. Lorsque ce contrôle échoue, le serveur renvoie un code de réponse 403 (Interdit).

System_CAPS_noteRemarque

Le x-ms-date en-tête est fournie car certaines bibliothèques de client HTTP et les proxys définissent automatiquement le Date en-tête et le développeur ne donnent pas une possibilité de lire sa valeur pour l'inclure dans la demande authentifiée. Si vous définissez x-ms-date, construisez la signature avec une valeur vide pour le Date en-tête.

Une demande authentifiée doit inclure le Authorization en-tête. Si cet en-tête n'est pas inclus, la demande est anonyme et ne peut réussir que pour un conteneur ou un objet blob marqué pour un accès public, ou pour un conteneur, un objet blob, une file d'attente ou une table pour lesquels une signature d'accès partagé a été fournie à des fins d'accès délégué.

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 la Authorization en-tête se présente comme suit :

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

SharedKey ou SharedKeyLite est le nom du schéma d'autorisation, AccountName est le nom du compte demandant la ressource, et Signature est un hachage HMAC-based Message Authentication Code () construits à partir de la demande et calculé à l'aide de l'algorithme SHA256 et puis codé en Base64.

System_CAPS_noteRemarque

Il est possible de demander une ressource qui réside sous un autre compte, si cette ressource est accessible publiquement.

Les sections suivantes décrivent comment construire le Authorization en-tête.

La construction de la chaîne de signature dépend du service et de la version que vous utilisez pour l'authentification et du schéma d'authentification. 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 PUT, et doit être en majuscule.

  • Pour l'authentification Shared Key pour les services BLOB, de File d'attente et de Fichier, chaque en-tête inclus dans la chaîne de signature ne peut s'afficher qu'une seule fois. Si un en-tête est en double, le service renvoie le code d'état 400 (Demande incorrecte).

  • 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.

  • Si le x-ms-date en-tête est spécifié, vous pouvez ignorer le Date en-tête, si elle est spécifiée dans la demande et simplement spécifier une ligne vide pour la Date partie de la chaîne de signature. Dans ce cas, suivez les instructions de la construction le CanonicalizedHeaders élément section pour ajouter la x-ms-date en-tête.

    Notez qu'il est acceptable de spécifier x-ms-date et Date; dans ce cas, le service utilise la valeur de x-ms-date.

  • Si le x-ms-date en-tête n'est pas spécifié, spécifiez la Date en-tête dans la chaîne de signature, sans inclure le nom d'en-tête.

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

  • La chaîne de signature inclut des en-têtes au format canonique et des chaînes de ressource au format canonique. La mise au format canonique de ces chaînes les place dans un format standard reconnu par Azure Storage. Pour plus d'informations sur la construction de la CanonicalizedHeaders et CanonicalizedResource chaînes 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 Shared Key dans une demande, dans les versions 2009-09-19 et ultérieures des services BLOB ou File d'attente, et dans les versions 2014-02-14 et ultérieures du service Fichier, 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 Get Blob opération. Notez que lorsqu'il n'existe aucune valeur d'en-tête, seul le caractère de nouvelle ligne est spécifié.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/ mycontainer\ncomp:metadata\nrestype:container\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 (include value when zero)*/ \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*/ x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/ /myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

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

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Notez que, pour utiliser l'authentification Shared Key avec les versions 2009-09-19 et ultérieures des services BLOB et File d'attente, vous devez mettre à jour votre code pour utiliser cette chaîne de signature augmentée.

Si vous préférez migrer votre code vers la version 2009-09-19 ou versions ultérieures de services Blob et de file d'attente avec les moins de changements possibles, vous pouvez modifier votre Authorization en-têtes pour utiliser Shared Key Lite au lieu de la clé partagée. Le format de signature requis par Shared Key Lite est le même que celui pour Shared Key par les versions des services BLOB et de File d'attente antérieurs au 19/09/2009.

System_CAPS_importantImportant

Si vous accédez à l'emplacement secondaire dans un compte de stockage pour lesquels la géo-réplication avec accès en lecture (RA-GRS) est activée, n'incluez pas le -secondary Désignation dans l'en-tête d'autorisation. À des fins d'autorisation, le nom du compte est toujours celui de l'emplacement principal, même pour un accès secondaire.

Lorsque vous utilisez la version 2015-02-21 ou version ultérieure, si Content-Length est égal à zéro, puis définissez la Content-Length dans le cadre de la StringToSign une chaîne vide.

Par exemple, pour la requête suivante, la valeur de la Content-Length en-tête est omise de la StringToSign lorsqu'il est zéro.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1 x-ms-version: 2015-02-21 x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08= Content-Length: 0

Le StringToSign est construite comme suit :

Version 2015-02-21 and later: PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Alors que dans les versions antérieures 2015-02-21, le StringToSign doit inclure la valeur zéro pour Content-Length:

Version 2014-02-14 and earlier: PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Vous devez utiliser l'authentification Shared Key pour authentifier une demande adressée au service de Table si votre service utilise l'API REST pour effectuer la demande. Le format de la chaîne de signature pour Shared Key auprès du service de Table est identique pour toutes les versions.

Notez que la chaîne de signature Shared Key pour une demande au service de Table diffère légèrement de celle d'une demande auprès du service Blob ou file d'attente, car elle n'inclut pas la CanonicalizedHeaders partie de la chaîne. En outre, le Date en-tête dans ce cas n'est jamais vide même si la demande définit la x-ms-date en-tête. Si la demande définit x-ms-date, que valeur est également utilisée pour la valeur de la Date en-tête.

Pour encoder la chaîne de signature pour une demande du service de Table effectuée à l'aide de l'API REST, utilisez le format suivant :

StringToSign = VERB + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Date + "\n" + CanonicalizedResource;

System_CAPS_noteRemarque

Depuis la version 2009-09-19, le service de Table nécessite que tous les appels REST incluent les DataServiceVersion et MaxDataServiceVersion les en-têtes. Consultez Configuration des en-têtes de version du service de données OData Pour plus d'informations.

Vous pouvez utiliser l'authentification Shared Key Lite pour authentifier une demande effectuée dans les versions 2009-09-19 et ultérieures des services BLOB et File d'attente, ou dans les versions 2014-02-14 et ultérieures du service Fichier.

La chaîne de signature pour Shared Key Lite est la même que celle pour l'authentification Shared Key dans les versions des services BLOB et de File d'attente antérieurs au 19/09/2009. Par conséquent, si vous souhaitez migrer votre code avec le moins de modifications à la version 2009-09-19 des services Blob et de file d'attente, vous pouvez modifier votre code pour utiliser Shared Key Lite, sans modifier la chaîne de signature. Notez qu'en utilisant l'authentification Shared Key Lite, vous ne bénéficierez pas de la fonctionnalité de sécurité renforcée fournie par Shared Key avec les versions 2009-09-19 et ultérieures.

Pour encoder la chaîne de signature pour une demande effectuée auprès du service BLOB ou de File d'attente, utilisez le format suivant :

StringToSign = VERB + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Date + "\n" + CanonicalizedHeaders + CanonicalizedResource;

L'exemple suivant montre une chaîne de signature pour une Put Blob opération. Notez que la ligne d'en-tête Content-MD5 est vide. Les en-têtes affichés dans la chaîne sont des paires nom-valeur qui spécifient les valeurs personnalisées de métadonnées du nouvel objet blob.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

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

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Vous pouvez utiliser l'authentification Shared Key Lite pour authentifier une demande effectuée avec une version quelconque du service de Table.

Pour encoder la chaîne de signature pour une demande du service de Table effectuée à l'aide de Shared Key Lite, utilisez le format suivant :

StringToSign = Date + "\n" CanonicalizedResource

L'exemple suivant montre une chaîne de signature pour une Create Table opération.

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

Ensuite, encodez cette chaîne à l'aide de l'algorithme HMAC-SHA256, construisez la Authorization en-tête, puis ajoutez l'en-tête à la demande. L'exemple suivant illustre la Authorization en-tête pour la même opération :

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

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

  1. Extraire tous les en-têtes de la ressource qui commencent par x-ms-, y compris la x-ms-date en-tête.

  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.

    System_CAPS_noteRemarque

    Ordre lexicographique ne peut pas toujours coïncider avec tri alphabétique conventionnelle.

  4. Dépliez la chaîne en remplaçant tous les espaces blancs par un seul espace.

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

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

L'exemple suivant illustre une chaîne d'en-tête au format canonique :

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

La CanonicalizedResource partie de la chaîne de signature représente la ressource de services de stockage ciblée par la requête. Une partie de la CanonicalizedResource chaîne qui est dérivée de l'URI de ressource doit être encodée exactement tel qu'il est dans l'URI.

Il existe deux formats pris en charge pour le CanonicalizedResource chaîne :

  • Un format qui prend en charge l'authentification Shared Key pour les versions 2009-09-19 et ultérieures des services BLOB et File d'attente, et pour les versions 2014-02-14 et ultérieures du service Fichier.

  • Un format qui prend en charge Shared Key et Shared Key Lite pour toutes les versions du service Table, et Shared Key Lite pour les versions 2009-09-19 et ultérieures des services BLOB et File d'attente. Ce format est le même que celui utilisé avec les versions précédentes des services de stockage.

Pour obtenir de l'aide sur la construction de l'URI pour la ressource à laquelle vous accédez, consultez l'une des rubriques suivantes :

System_CAPS_importantImportant

Si votre compte de stockage est répliquée avec réplication géographique avec accès en lecture (RA-GRS) et que vous accédez à une ressource dans l'emplacement secondaire, n'incluez pas le –secondary Désignation dans le CanonicalizedResource chaîne. La ressource URI utilisé dans le CanonicalizedResource chaîne URI doit être l'URI de la ressource à l'emplacement principal.

System_CAPS_noteRemarque

Si vous authentifiez auprès de l'émulateur de stockage, le nom du compte apparaîtra deux fois dans le CanonicalizedResource chaîne. Ce comportement est attendu. Si vous authentifiez auprès des services de stockage Azure, le nom du compte apparaît qu'une seule fois dans le CanonicalizedResource chaîne.

Format de clé partagée des versions 2009-09-19 et ultérieures

Ce format prend en charge l'authentification Shared Key pour les versions 2009-09-19 et ultérieures des services BLOB et File d'attente, et pour les versions 2014-02-14 et ultérieures du service Fichier. Construire le CanonicalizedResource au format de chaîne comme suit :

  1. En commençant avec une chaîne vide (""), ajoutez une barre oblique (/), suivie du nom du compte propriétaire de la ressource à laquelle vous accédez.

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

  3. Ajoutez un caractère de nouvelle ligne (\n) après le nom de ressource.

  4. Récupérer tous les paramètres de requête sur la ressource URI, y compris la comp paramètre si elle existe.

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

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

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

  8. 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

  9. 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

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

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.

Voici quelques exemples qui montrent la CanonicalizedResource partie de la signature de chaîne, comme elle peut être construite à partir d'un URI de demande donné :


Get Container Metadata GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata CanonicalizedResource: /myaccount/mycontainer\ncomp:metadata\nrestype:container List Blobs operation: GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs CanonicalizedResource: /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container Get Blob operation against a resource in the secondary location: GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob CanonicalizedResource: /myaccount/mycontainer/myblob


Versions 2009-09-19 et ultérieures de Shared Key Lite et format du service Table

Ce format prend en charge Shared Key et Shared Key Lite pour toutes les versions du service Table, et Shared Key Lite pour les versions 2009-09-19 et ultérieures des services BLOB et File d'attente, et pour les versions 2014-02-14 et ultérieures du service Fichier. Ce format est le même que celui utilisé avec les versions précédentes des services de stockage. Construire le CanonicalizedResource au format de chaîne comme suit :

  1. En commençant avec une chaîne vide (""), ajoutez une barre oblique (/), suivie du nom du compte propriétaire de la ressource à laquelle vous accédez.

  2. Ajoutez le chemin URI encodé de la ressource. Si l'URI de demande adresse un composant de la ressource, ajoutez la chaîne de requête appropriée. La chaîne de requête doit inclure le point d'interrogation et le comp paramètre (par exemple, ?comp=metadata). Aucun autre paramètre ne doit être inclus dans la chaîne de requête.

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)))
Afficher: