Autoriser avec une clé partagée

Toute demande faite contre un service d’entreposage doit être autorisée, à moins que la demande ne porte sur une ressource de blob ou de conteneurs qui a été mise à la disposition du public ou de la signature. Une option pour autoriser une demande est d’utiliser La clé partagée, décrite dans cet article.

Conseil

Azure Storage soutient l’intégration avec Azure Active Directory pour un contrôle à grain fin sur l’accès aux ressources de stockage. L’intégration Azure AD est prise en charge pour les services Blob et Queue. Étant donné qu’Azure AD assure la gestion de l’identité, vous pouvez autoriser l’accès aux ressources de stockage sans stocker les clés d’accès de votre compte dans vos applications, comme vous le faites avec La clé partagée. Pour plus d’informations, voir Authorize with Azure Active Directory.

Les services Blob, Queue, Table et File prennent en charge les systèmes d’autorisation clés partagées suivants pour la version 2009-09-19 et plus tard (pour le service Blob, Queue et Table) et la version 2014-02-14 et plus tard (pour le service de fichiers) et plus tard (pour le service de fichiers) et la version 2014-02-14 et plus tard (pour le service de fichiers) :

  • Shared Key pour les services BLOB, de File d'attente et de Fichier. Utilisez le système d’autorisation de clé partagée pour faire des demandes contre les services Blob, Queue et Fichier. Autorisation de clé partagée dans la version 2009-09-19 et prend en charge plus tard une chaîne de signature augmentée pour une sécurité accrue et exige que vous actualisez votre service pour autoriser l’utilisation de cette signature augmentée.

  • Shared Key pour le service de Table. Utilisez le système d’autorisation de clé partagée pour faire des demandes contre le service Table à l’aide de l’API REST. Autorisation de clé partagée pour le service Table dans la version 2009-09-19 et utilise plus tard la même chaîne de signature que dans les versions précédentes du service Table.

  • Shared Key Lite. Utilisez le système d’autorisation de Lite Clé Partagée pour faire des demandes contre les services Blob, Queue, Table et File.

    Pour la version 2009-09-19 et plus tard des services Blob et Queue, l’autorisation De lite clé partagée prend en charge l’utilisation d’une chaîne de signature identique à ce qui a été pris en charge contre la clé partagée dans les versions précédentes des services Blob et Queue. 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 autorisée nécessite deux Date en-têtes : l’en-tête et x-ms-date l’en-tête. Authorization Les sections suivantes décrivent comment construire ces en-têtes.

Important

Azure Storage support à la fois HTTP et HTTPS, mais en utilisant HTTPS est fortement recommandé.

Notes

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, voir Manage Access to Azure Storage Resources. Un conteneur, un blob, une file d’attente ou une table peuvent être disponibles pour un accès signé via une signature d’accès partagé; une signature d’accès partagé est autorisée par un mécanisme différent. Voir l’accès délégué avec une signature d’accès partagé pour plus de détails.

Spécifier l’en-tête Date

Toutes les demandes autorisées doivent inclure l’alluoire de temps universel coordonné (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 renvoie un code de réponse 403 (Interdit).

Notes

L’en-tête x-ms-date est fourni parce que certaines Date bibliothèques de clients HTTP et procurations fixent automatiquement l’en-tête, et ne donnent pas au développeur l’occasion de lire sa valeur afin de l’inclure dans la demande autorisée. Si vous définissez x-ms-date, construisez la signature avec une valeur vide pour l'en-tête Date.

Spécifier l’en-tête d’autorisation

Une demande autorisée doit Authorization inclure l’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 autoriser une demande, vous devez signer la demande avec la clé du compte qui fait la demande et transmettre 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.

Notes

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.

Construire la chaîne de signature

La façon dont vous construisez la chaîne de signature dépend du service et de la version que vous autorisez et du système d’autorisation que vous utilisez. 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’autorisation de clé partagée pour les services Blob, Queue et Fichier, chaque en-tête inclus dans la chaîne de signature ne peut apparaître 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 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 dans la construction de la x-ms-date section de chaîne d’en-têtes canonisé pour ajouter l’en-tête.

    Il est acceptable x-ms-date de Datespécifier à la fois et ; dans ce cas, le service x-ms-dateutilise la valeur de .

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

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

Blob, File d’attente et services de fichiers (autorisation de clé partagée)

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;  

Important

Dans la version actuelle, le champ Content-Length doit être une chaîne vide si la durée du contenu de la demande est nulle. Dans la version 2014-02-14 et plus tôt, la durée du contenu a été incluse même si zéro. Voir ci-dessous pour plus d’informations sur le vieux comportement.

L’exemple suivant montre une chaîne de signature pour une opération Get Blob. Lorsqu’il n’y a pas de valeur d’en-tête, le caractère de nouvelle ligne est uniquement spécifié.

GET\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\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 (empty string 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:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/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=  

Pour utiliser l’autorisation De clé partagée avec la version 2009-09-19 et plus tard des services Blob et Queue, 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 plus tard des services Authorization Blob et Queue avec le moins de modifications possibles, vous pouvez modifier vos en-têtes existants 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.

Important

Si vous accédez à l'emplacement secondaire dans un compte de stockage pour lequel la géo-réplication avec accès en lecture (RA-GRS) est activée, n'incluez pas la désignation -secondary 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.

En-tête contenu-Longueur dans la version 2014-02-14 et plus tôt

Lorsque vous utilisez la version 2014-02-14 ou plus tôt, Content-Length si elle est nulle, puis définissez la Content-Length partie de la StringToSign à 0. Normalement, ce serait une chaîne vide.

Par exemple, pour la demande suivante, la valeur de l’en-tête Content-Length est incluse dans l’en-cas StringToSign même lorsqu’il est nul.

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

Le StringToSign est construit comme suit:

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:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Alors que dans les versions après 2014-02-14, le StringToSign doit contenir une chaîne vide pour Content-Length:

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

Service de table (autorisation de clé partagée)

Vous devez utiliser l’autorisation de clé partagée pour autoriser une demande faite contre le service Table si votre service utilise l’API REST pour faire 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.

La chaîne de signature de clé partagée pour une demande contre le service table diffère légèrement de celle CanonicalizedHeaders d’une demande contre le service Blob ou Queue, en ce qu’elle n’inclut pas la partie 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;  

Notes

À 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. Voir Définir les en-têtes de version de service de données OData pour plus d’informations.

Blob, File d’attente et services de fichiers (autorisation de lite clé partagée)

Vous pouvez utiliser l’autorisation De lite clé partagée pour autoriser une demande faite contre la version 2009-09-19 et plus tard des services Blob et Queue, et la version 2014-02-14 et plus tard des services de fichier.

La chaîne signature pour Shared Key Lite est identique à la chaîne de signature requise pour l’autorisation de clé partagée dans les versions des services Blob et Queue avant 2009-09-19. Donc, si vous souhaitez migrer votre code avec le moins de modifications à la version 2009-09-19 des services Blob et Queue, vous pouvez modifier votre code pour utiliser Shared Key Lite, sans changer la chaîne de signature elle-même. En utilisant Shared Key Lite, vous n’obtenirez pas la fonctionnalité de sécurité améliorée fournie en utilisant la clé partagée avec la version 2009-09-19 et plus tard.

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 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=  

Service de table (autorisation de lite clé partagée)

Vous pouvez utiliser l’autorisation De lite clé partagée pour autoriser une demande faite contre n’importe quelle version du service 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 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=  

Construire la chaîne d’en-têtes canonisé

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. Chaque en-tête ne peut s'afficher qu'une seule fois dans la chaîne.

    Notes

    L’ordre lexicographique ne coïncide pas toujours avec l’ordre alphabétique conventionnel.

  4. Remplacez n’importe quel espace blanc linéaire dans la valeur d’en-tête par un seul espace.

L’espace blanc linéaire comprend l’alimentation de retour/ligne de transport (CRLF), les espaces et les onglets. Voir RFC 2616, section 4.2 pour plus de détails. Ne remplacez aucun espace blanc à l’intérieur d’une chaîne citée.

  1. Couper n’importe quel espace blanc autour du côlon dans l’en-tête.

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

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

Notes

Avant la version de service 2016-05-31, les en-têtes avec des valeurs vides ont été omis de la chaîne de signature. Ceux-ci sont maintenant représentés dans CanonicalizedHeaders en suivant immédiatement le personnage du côlon avec la nouvelle ligne de fin.

Construire la chaîne de ressources canonisée

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’autorisation de clé partagée pour la version 2009-09-19 et plus tard des services Blob et Queue, et pour la version 2014-02-14 et plus tard du service de fichiers.

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

Important

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

Notes

Si vous autorisez contre l’émulateur de stockage, CanonicalizedResource le nom du compte apparaîtra deux fois dans la chaîne. Ceci est normal. Si vous autorisez contre les services de stockage Azure, CanonicalizedResource le nom du compte n’apparaîtra qu’une seule fois dans la chaîne.

Format clé partagé pour 2009-09-19 et plus tard

Ce format prend en charge l’autorisation de clé partagée pour la version 2009-09-19 et plus tard des services Blob et Queue, ainsi que la version 2014-02-14 et plus tard des services De fichiers. 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. Inclure un caractère nouvelle ligne avant chaque paire de valeur nominale.

  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

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  
  
Get Blob operation against a resource in the secondary location:  
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob  
CanonicalizedResource:  
    /myaccount/mycontainer/myblob

Format de service clé Lite et Table partagé pour 2009-09-19 et plus tard

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

Codage 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. Notez que vous devez également décoder votre clé de compte de stockage Base64. Utilisez le format suivant (affiché comme pseudocode) :

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))  

Voir aussi