VENTES: 1-800-867-1389

Authentification pour les services de stockage Azure

Mis à jour: mai 2014

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

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, de File d'attente, de Table et de Fichier prennent en charge les schémas d'authentification Shared Key, à partir de la version du 19/09/2009 pour les services BLOB, de File d'attente et de Table, et à partir de la version du 14/02/2014 pour le service de Fichier :

  • Shared Key pour les services BLOB, de File d'attente et de Fichier. Utilisez le schéma d'authentification Shared Key pour effectuer des demandes aux services BLOB, de File d'attente et de Fichier. L'authentification Shared Key dans la version du 19/09/2009 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 en utilisant cette signature augmentée.

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

  • Shared Key Lite. Utilisez le schéma d'authentification Shared Key Lite pour effectuer des demandes aux services BLOB, de File d'attente, de Table et de Fichier.

    Pour la version du 19/09/2009 des services BLOB et de File d'attente, l'authentification Shared Key Lite est prise en charge en utilisant une chaîne de signature identique à celle prise en charge pour Shared Key dans les versions antérieures des services BLOB et de 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 : l'en-tête Date ou x-ms-date et l'en-tête Authorization. Les sections suivantes décrivent comment construire ces en-têtes.

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 Windows 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. Pour plus d'informations, consultez Délégation de l'accès avec une signature d'accès partagé.

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

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 retourne un code de réponse 403 (Interdit).

noteRemarque
L'en-tête x-ms-date est fourni car certaines bibliothèques et proxy client HTTP définissent automatiquement l'en-tête Date, et ne donnent pas aux développeurs la possibilité de lire sa valeur afin de l'inclure dans la demande authentifiée. Si vous définissez x-ms-date, construisez la signature avec une valeur vide pour l'en-tête Date.

Une demande authentifiée doit inclure l'en-tête Authorization. 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 l'en-tête Authorization est le suivant :

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 le HMAC (Hash-based Message Authentication Code) construit à partir de la demande et calculé en utilisant l'algorithme SHA256, puis encodé en Base64.

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 l'en-tête Authorization.

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 retourne 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 l'en-tête x-ms-date est spécifié, vous pouvez ignorer l'en-tête Date, qu'il soit ou non spécifié dans la demande, et simplement spécifier une ligne vide pour la partie Date de la chaîne de signature. Dans ce cas, suivez les instructions de la section Construction l'élément CanonicalizedHeaders pour ajouter l'en-tête x-ms-date.

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

  • Si l'en-tête x-ms-date n'est pas spécifié, spécifiez l'en-tête Date 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.

  • Pour plus d'informations sur la construction de 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 Shared Key dans une demande effectuée avec la version du 19/09/2009 ou ultérieure du service BLOB ou de File d'attente, ou avec la version du 14/02/2014 du service de 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 illustre une chaîne de signature pour une opération Get Blob. 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/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*/
\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/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

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

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Notez qu'afin d'utiliser l'authentification Shared Key avec les versions du 19/09/2009 des services BLOB et de 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 les versions du 19/09/2009 des services BLOB et de File d'attente avec le moins de changements possibles, vous pouvez modifier vos en-têtes existants Authorization pour utiliser Shared Key au lieu de Shared Key Lite. 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.

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 de service de Table diffère légèrement de celle d'une demande auprès des services BLOB ou de File d'attente, car elle n'inclut pas la partie CanonicalizedHeaders de la chaîne. En outre, l'en-tête Date n'est jamais vide même si la demande définit l'en-tête x-ms-date. Si la demande définit x-ms-date, cette valeur est également utilisée pour la valeur de l'en-tête Date.

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;

noteRemarque
À partir de la version du 19/09/2009, le service de Table requiert que tous les appels REST comprennent les en-têtes DataServiceVersion et MaxDataServiceVersion. Pour plus d'informations, consultez Configuration des en-têtes de version du service de données OData.

Vous pouvez utiliser l'authentification Shared Key Lite pour authentifier une demande effectuée avec la version du 19/09/2009 des services BLOB et de File d'attente ou avec la version du 14/02/2014 du service de Fichier.

La chaîne de signature de Shared Key Lite est identique à celle requise pour l'authentification Shared Key dans les versions des services BLOB et de File d'attente antérieures au 19/09/2009. Si vous voulez migrer votre code avec le moins possible de modifications apportées aux versions du 19/09/2009 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 elle-même. Notez qu'en utilisant Shared Key Lite, vous ne bénéficierez pas de la fonctionnalité de sécurité renforcée fournie par Shared Key avec la version du 19/09/2009 de l'API.

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 illustre une chaîne de signature pour une opération Put Blob. 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 à l'aide de l'algorithme HMAC-SHA256 dans la chaîne de signature encodée en UTF-8, construisez l'en-tête Authorization, et ajoutez l'en-tête à la demande. L'exemple suivant montre l'en-tête Authorization 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 illustre une chaîne de signature pour une opération Create Table.

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

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

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

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

  1. Récupérez tous les en-têtes pour la ressource qui commencent par x-ms-, notamment l'en-tête x-ms-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. Notez que chaque en-tête ne peut s'afficher qu'une seule fois dans la chaîne.

  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. Construisez la chaîne CanonicalizedHeaders en concaténant tous les en-têtes de cette liste en une chaîne unique.

La partie CanonicalizedResource de la chaîne de signature représente la ressource de services de stockage ciblé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.

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

  • Un format qui prend en charge l'authentification Shared Key pour la version du 19/09/2009 des services BLOB et de File d'attente, et pour la version du 14/02/2014 du service de Fichier.

  • Un format qui prend en charge Shared Key et Shared Key Lite pour toutes les versions du service de Table, et Shared Key Lite pour la version du 19/09/2009 des services BLOB et de 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 :

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

Format Shared Key du 19/09/2009

Ce format prend en charge l'authentification Shared Key pour la version du 19/09/2009 des services BLOB et de File d'attente, et pour la version du 14/02/2014 du service de Fichier. Construisez la chaîne CanonicalizedResource dans ce format 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. Récupérez tous les paramètres de requête de l'URI de ressource, notamment le paramètre comp s'il existe.

  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.

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 contenant la partie CanonicalizedResource de la chaîne de signature, telle qu'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

Format du service de Table et Shared Key Lite du 19/09/2009

Ce format prend en charge Shared Key et Shared Key Lite pour toutes les versions du service de Table. Il prend en charge Shared Key Lite pour la version du 19/09/2009 des services BLOB et de File d'attente, et pour la version du 14/02/2014 du service de Fichier. Ce format est le même que celui utilisé avec les versions précédentes des services de stockage. Construisez la chaîne CanonicalizedResource dans ce format 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 paramètre comp (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)))

Voir aussi

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft