Autoriser avec une clé partagée

Article
11/18/2024

Chaque requête effectuée auprès d’un service de stockage doit être autorisée, sauf si la demande concerne une ressource d’objet blob ou de conteneur qui a été rendue disponible pour l’accès public ou signé. L’une des options permettant d’autoriser une demande consiste à utiliser la clé partagée, décrite dans cet article.

Important

Pour une sécurité optimale, Microsoft recommande d’utiliser l’ID Microsoft Entra avec des identités managées pour autoriser les demandes sur les données d’objet blob, de file d’attente et de table, dans la mesure du possible. L’autorisation avec l’ID Microsoft Entra et les identités managées offre une sécurité et une facilité d’utilisation supérieures sur l’autorisation de clé partagée. Pour plus d’informations, consultez Autoriser avec microsoft Entra ID. Pour en savoir plus sur les identités managées, consultez Qu’est-ce que les identités managées pour les ressources Azure.

Pour les ressources hébergées en dehors d’Azure, telles que les applications locales, vous pouvez utiliser des identités managées via Azure Arc. Par exemple, les applications s’exécutant sur des serveurs avec Azure Arc peuvent utiliser des identités managées pour se connecter aux services Azure. Pour plus d’informations, consultez s’authentifier sur des ressources Azure avec des serveurs avec Azure Arc.

Pour les scénarios où les signatures d’accès partagé (SAP) sont utilisées, Microsoft recommande d’utiliser une SAP de délégation d’utilisateur. Une SAP de délégation d’utilisateur est sécurisée avec les informations d’identification Microsoft Entra au lieu de la clé de compte. Pour en savoir plus sur les signatures d’accès partagé, consultez Créer une SAP de délégation d’utilisateur.

Les services Blob, File d’attente, Table et Fichier prennent en charge les schémas d’autorisation de clé partagée suivants pour la version 2009-09-19 et versions ultérieures (pour le service Blob, File d’attente et Table) et la version 2014-02-14 et ultérieures (pour le service de fichiers) :

Clé partagée pour les services d’objets blob, de file d’attente et de fichiers. Utilisez le schéma d’autorisation de clé partagée pour effectuer des requêtes sur les services Blob, File d’attente et File d’attente. L’autorisation de clé partagée dans la version 2009-09-19 et ultérieure prend en charge une chaîne de signature augmentée pour une sécurité renforcée et vous oblige à mettre à jour votre service pour autoriser l’utilisation de cette signature augmentée.
Clé partagée pour le service de table. Utilisez le schéma d’autorisation de clé partagée pour effectuer des requêtes sur le service Table à l’aide de l’API REST. L’autorisation de clé partagée pour le service table dans la version 2009-09-19 et ultérieure utilise la même chaîne de signature que dans les versions précédentes du service Table.
Clé partagée Lite. Utilisez le schéma d’autorisation Shared Key Lite pour effectuer des requêtes sur les services Blob, File d’attente, Table et Fichier. Shared Key Lite n’est pas pris en charge pour les objets blob de pages Premium.

Pour la version 2009-09-19 et ultérieure des services Blob et File d’attente, l’autorisation Shared Key Lite prend en charge l’utilisation d’une chaîne de signature identique à celle prise en charge par rapport à la clé partagée dans les versions précédentes des services Blob et File d’attente. Vous pouvez donc utiliser Shared Key Lite pour effectuer des requêtes auprès des services Blob et File d’attente sans mettre à jour votre chaîne de signature.

Une demande autorisée nécessite 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.

Important

Stockage Azure prend en charge HTTP et HTTPS, mais l’utilisation de HTTPS est vivement recommandée.

Note

Un conteneur ou un objet blob peut être mis à disposition 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. Un conteneur, un objet blob, une file d’attente ou une table peut être mis à disposition pour l’accès signé via une signature d’accès partagé ; Une signature d’accès partagé est autorisée par le biais d’un autre mécanisme. Pour plus d’informations, consultez Déléguer l’accès avec une signature d’accès partagé.

Spécification de l’en-tête Date

Toutes les demandes autorisées doivent inclure l’horodatage UTC (Temps universel coordonné) de 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 sur la demande, la valeur de x-ms-date est utilisée comme heure de création de la requête.

Les services de stockage garantissent qu’une demande n’est pas antérieure à 15 minutes au moment où elle atteint le service. Cela protège contre certaines attaques de sécurité, y compris les attaques de relecture. Lorsque cette vérification échoue, le serveur retourne le code de réponse 403 (Interdit).

Note

L’en-tête x-ms-date est fourni, car certaines bibliothèques clientes et proxys HTTP définissent automatiquement l’en-tête Date et ne donnent pas au développeur la possibilité 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écification de l’en-tête d’autorisation

Une demande autorisée doit inclure l’en-tête Authorization. Si cet en-tête n’est pas inclus, la requête est anonyme et réussit uniquement par rapport à un conteneur ou un objet blob marqué pour l’accès public, ou par rapport à un conteneur, un objet blob, une file d’attente ou une table pour laquelle une signature d’accès partagé a été fournie pour l’accès délégué.

Pour autoriser une demande, vous devez signer la demande avec la clé du compte qui effectue 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>"

où SharedKey ou SharedKeyLite est le nom du schéma d’autorisation, AccountName est le nom du compte demandant la ressource, et Signature est un code d’authentification de message basé sur le hachage (HMAC) construit à partir de la requête et calculé à l’aide de l’algorithme SHA256, puis encodé à l’aide de l’encodage Base64.

Note

Il est possible de demander une ressource qui se trouve sous un autre compte, si cette ressource est accessible publiquement.

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

Construction de 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 par rapport au schéma d’autorisation que vous utilisez. Lors de la construction de la chaîne de signature, gardez à l’esprit les éléments suivants :

La partie VERB de la chaîne est le verbe HTTP, tel que GET ou PUT, et doit être en majuscules.
Pour l’autorisation de clé partagée pour les services Blob, File d’attente 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 dupliqué, le service retourne le code d’état 400 (demande incorrecte).
Les valeurs de tous les en-têtes HTTP standard doivent être incluses dans la chaîne dans l’ordre indiqué dans le format de signature, sans les noms d’en-têtes. 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 requis.
Si l’en-tête x-ms-date est spécifié, vous pouvez ignorer l’en-tête Date, qu’il soit spécifié sur la demande et spécifier simplement une ligne vide pour la partie Date de la chaîne de signature. Dans ce cas, suivez les instructions de la Construction de la chaîne d’en-têtes canoniques section pour ajouter l’en-tête x-ms-date.

Il est acceptable de spécifier à la fois x-ms-date et Date; dans ce cas, le service utilise la valeur de 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 de l’en-tête.
Tous les caractères de nouvelle ligne (\n) affichés sont requis dans la chaîne de signature.
La chaîne de signature inclut des en-têtes canoniques et des chaînes de ressources canoniques. La canonisation de ces chaînes les place dans un format standard reconnu par stockage Azure. 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.

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

Pour encoder la chaîne de signature de clé partagée pour une requête sur la version 2009-09-19 et ultérieure du service Blob ou File d’attente, et la version 2014-02-14 et ultérieures du service de fichiers, 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 longueur du contenu de la requête est égale à zéro. Dans la version 2014-02-14 et antérieure, la longueur du contenu a été incluse même si zéro. Pour plus d’informations sur l’ancien comportement, consultez ci-dessous.

L’exemple suivant montre une chaîne de signature pour une opération Obtenir un objet blob. Lorsqu’il n’existe aucune valeur d’en-tête, le caractère de nouvelle ligne est spécifié uniquement.

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 de cette ligne par ligne montre chaque partie 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 sur la chaîne de signature encodée 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=

Pour utiliser l’autorisation de clé partagée avec la version 2009-09-19 et ultérieure 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 ultérieure des services Blob et File d’attente avec les modifications les plus rares possibles, vous pouvez modifier vos en-têtes de Authorization existants pour utiliser Shared Key Lite au lieu de la clé partagée. Le format de signature requis par Shared Key Lite est identique à celui requis pour la clé partagée par les versions des services Blob et File d’attente antérieures à 2009-09-19.

Important

Si vous accédez à l’emplacement secondaire dans un compte de stockage pour lequel la géoréplication à 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 le nom de l’emplacement principal, même pour l’accès secondaire.

En-tête Content-Length dans la version 2014-02-14 et versions antérieures

Lorsque vous utilisez la version 2014-02-14 ou antérieure, si Content-Length est égal à zéro, définissez la partie Content-Length du StringToSign sur 0. Normalement, il s’agit d’une chaîne vide.

Par exemple, pour la requête suivante, la valeur de l’en-tête Content-Length est incluse dans le StringToSign même lorsqu’il est égal à zéro.

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 postérieures à 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 effectuée sur le service Table si votre service utilise l’API REST pour effectuer la requête. Le format de la chaîne de signature pour la clé partagée par rapport au service Table est le même pour toutes les versions.

La chaîne de signature de clé partagée pour une requête sur le service Table diffère légèrement de celle d’une requête par rapport au service Blob ou File d’attente, car elle n’inclut pas la partie CanonicalizedHeaders de la chaîne. En outre, l’en-tête Date dans ce cas n’est jamais vide même si la requête définit l’en-tête x-ms-date. Si la requête 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 d’une requête sur le service 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;

Note

À compter de la version 2009-09-19, le service Table nécessite que tous les appels REST incluent les en-têtes DataServiceVersion et MaxDataServiceVersion. Pour plus d’informations, consultez Définition des en-têtes de version du service de données OData.

Services d’objets blob, de file d’attente et de fichiers (autorisation Shared Key Lite)

Vous pouvez utiliser l’autorisation Shared Key Lite pour autoriser une demande effectuée sur la version 2009-09-19 et ultérieure des services Blob et File d’attente, et la version 2014-02-14 et ultérieure des services de fichiers. Shared Key Lite n’est pas pris en charge pour les objets blob de pages Premium.

La chaîne de 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 File d’attente antérieures à 2009-09-19. Par conséquent, si vous souhaitez migrer votre code avec le moins de modifications apportées à la version 2009-09-19 des services Blob et File d’attente, vous pouvez modifier votre code pour utiliser Shared Key Lite, sans modifier la chaîne de signature elle-même. En utilisant Shared Key Lite, vous n’obtiendrez pas la fonctionnalité de sécurité améliorée fournie à l’aide de la clé partagée avec la version 2009-09-19 et ultérieure.

Pour encoder la chaîne de signature d’une requête sur le service Blob ou 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 des valeurs de métadonnées personnalisées pour le 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

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

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

Vous pouvez utiliser l’autorisation Shared Key Lite pour autoriser une demande effectuée sur n’importe quelle version du service Table.

Pour encoder la chaîne de signature d’une requête sur le service Table à 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 Créer une 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, puis ajoutez l’en-tête à la requête. L’exemple suivant montre l’en-tête Authorization pour la même opération :

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

Construction de la chaîne d’en-têtes canoniques

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

Récupérez tous les en-têtes de la ressource commençant par x-ms-, y compris l’en-tête x-ms-date.
Convertissez chaque nom d’en-tête HTTP en minuscules.
Triez les en-têtes lexicographiquement par nom d’en-tête, dans l’ordre croissant. Chaque en-tête ne peut apparaître qu’une seule fois dans la chaîne.

Note

classement lexicographique peut ne pas toujours coïncider avec l’ordre alphabétique conventionnel.
Remplacez tout espace blanc linéaire dans la valeur d’en-tête par un espace unique.

L’espace blanc linéaire comprend le retour chariot/saut de ligne (CRLF), les espaces et les onglets. Pour plus d’informations, consultez RFC 2616, section 4.2. Ne remplacez aucun espace blanc à l’intérieur d’une chaîne entre guillemets.

Découpez les espaces blancs autour du signe deux-points dans l’en-tête.
Enfin, ajoutez un caractère de nouvelle ligne à chaque en-tête canonique dans la liste résultante. Construisez la chaîne CanonicalizedHeaders en concaténant tous les en-têtes de cette liste en une seule chaîne.

Voici un exemple de chaîne d’en-têtes canoniques :

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

Note

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. Celles-ci sont désormais représentées dans CanonicalizedHeaders en suivant immédiatement le caractère deux-points avec la fin de la nouvelle ligne.

Construction de la chaîne de ressource canonique

La partie CanonicalizedResource de la chaîne de signature représente la ressource des services de stockage ciblée par la requête. Toute partie de la chaîne CanonicalizedResource 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 :

Format qui prend en charge l’autorisation de clé partagée pour la version 2009-09-19 et ultérieure des services Blob et File d’attente, et pour la version 2014-02-14 et ultérieure du service de fichiers.
Format qui prend en charge la clé partagée et la clé partagée Lite pour toutes les versions du service De table, et shared Key Lite pour la version 2009-09-19 et versions ultérieures des services Blob et File d’attente. Ce format est identique à 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 :

Service d’objets blob : nommage et référencement de conteneurs, d’objets blob et de métadonnées
Service de file d’attente : adressage des ressources du service de file d’attente
Service de table : adressage des ressources du service table
Service de fichiers : nommage et référencement de partages, répertoires, fichiers et métadonnées

Important

Si votre compte de stockage est répliqué avec la géoréplication en lecture (RA-GRS), et que vous accédez à une ressource à 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.

Note

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

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

Ce format prend en charge l’autorisation de clé partagée pour la version 2009-09-19 et ultérieure des services Blob et File d’attente, ainsi que la version 2014-02-14 et ultérieure des services de fichiers. Construisez la chaîne CanonicalizedResource dans ce format comme suit :

À compter d’une chaîne vide ( » « ), ajoutez une barre oblique (/), suivie du nom du compte propriétaire de la ressource accessible.
Ajoutez le chemin d’ACCÈS d’URI encodé de la ressource, sans aucun paramètre de requête.
Récupérez tous les paramètres de requête sur l’URI de ressource, y compris le paramètre comp s’il existe.
Convertissez tous les noms de paramètres en minuscules.
Triez les paramètres de requête lexicographiquement par nom de paramètre, dans l’ordre croissant.
Décodage d’URL chaque nom et valeur de paramètre de requête.
Incluez un caractère de nouvelle ligne (\n) avant chaque paire nom-valeur.
Ajoutez chaque nom et valeur de paramètre de requête à la chaîne au format suivant, en veillant à inclure le signe deux-points (:) entre le nom et la valeur :

parameter-name:parameter-value
Si un paramètre de requête a plusieurs valeurs, triez toutes les valeurs lexicographiquement, 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 canonique :

Évitez d’utiliser le caractère de nouvelle ligne (\n) dans les valeurs des paramètres de requête. S’il doit être utilisé, assurez-vous qu’il n’affecte pas le format de la chaîne de ressource canonique.
Évitez d’utiliser des virgules dans les valeurs des paramètres de requête.

Voici quelques exemples qui montrent la partie CanonicalizedResource de la chaîne de signature, car elle peut être construite à partir d’un URI de requête 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 Key Lite et Table partagés pour 2009-09-19 et versions ultérieures

Ce format prend en charge la clé partagée et la clé partagée Lite pour toutes les versions du service Table, et Shared Key Lite pour la version 2009-09-19 et ultérieures des services Blob et File d’attente et version 2014-02-14 et ultérieures du service de fichiers. Ce format est identique à celui utilisé avec les versions précédentes des services de stockage. Construisez la chaîne CanonicalizedResource dans ce format comme suit :

À compter d’une chaîne vide ( » « ), ajoutez une barre oblique (/), suivie du nom du compte propriétaire de la ressource accessible.
Ajoutez le chemin d’URI encodé de la ressource. Si l’URI de requête traite 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.

Encodage de la signature

Pour encoder la signature, appelez l’algorithme HMAC-SHA256 sur la chaîne de signature encodée UTF-8 et encodez le résultat en base64. Notez que vous devez également décoder en base64 votre clé de compte de stockage. Utilisez le format suivant (illustré sous forme de pseudocode) :

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

Partager via

Autoriser avec une clé partagée

Spécification de l’en-tête Date

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

Construction de la chaîne de signature

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

En-tête Content-Length dans la version 2014-02-14 et versions antérieures

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

Services d’objets blob, de file d’attente et de fichiers (autorisation Shared Key Lite)

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

Construction de la chaîne d’en-têtes canoniques

Construction de la chaîne de ressource canonique

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

Format de service Key Lite et Table partagés pour 2009-09-19 et versions ultérieures

Encodage de la signature

Voir aussi

Ressources supplémentaires