Delen via

Autoriseren met gedeelde sleutel

  • Artikel

Elke aanvraag op basis van een opslagservice moet worden geautoriseerd, tenzij de aanvraag is bedoeld voor een blob- of containerresource die beschikbaar is gesteld voor openbare of ondertekende toegang. Eén optie voor het autoriseren van een aanvraag is het gebruik van een gedeelde sleutel, zoals beschreven in dit artikel.

Belangrijk

Voor optimale beveiliging raadt Microsoft aan om Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen te autoriseren voor blob-, wachtrij- en tabelgegevens, indien mogelijk. Autorisatie met Microsoft Entra ID en beheerde identiteiten biedt superieure beveiliging en gebruiksgemak ten opzichte van autorisatie van gedeelde sleutels. Zie Autoriseren met Microsoft Entra IDvoor meer informatie. Zie Wat zijn beheerde identiteiten voor Azure-resourcesvoor meer informatie over beheerde identiteiten.

Voor resources die buiten Azure worden gehost, zoals on-premises toepassingen, kunt u beheerde identiteiten gebruiken via Azure Arc. Apps die worden uitgevoerd op servers met Azure Arc kunnen bijvoorbeeld beheerde identiteiten gebruiken om verbinding te maken met Azure-services. Zie Verifiëren bij Azure-resources met servers met Azure Arcvoor meer informatie.

Voor scenario's waarin SHARED Access Signatures (SAS) worden gebruikt, raadt Microsoft aan een SAS voor gebruikersdelegering te gebruiken. Een SAS voor gebruikersdelegering wordt beveiligd met Microsoft Entra-referenties in plaats van de accountsleutel. Zie Sas-voor gebruikersdelegering maken voor meer informatie over handtekeningen voor gedeelde toegang.

De services Blob, Queue, Table en File ondersteunen de volgende autorisatieschema's voor gedeelde sleutels voor versie 2009-09-19 en hoger (voor blob-, wachtrij- en tabelservice) en versie 2014-02-14 en hoger (voor bestandsservice):

  • Gedeelde sleutel voor blob-, wachtrij- en bestandsservices. Gebruik het autorisatieschema voor gedeelde sleutels om aanvragen uit te voeren voor de blob-, wachtrij- en bestandsservices. Autorisatie van gedeelde sleutels in versie 2009-09-19 en hoger ondersteunt een uitgebreide handtekeningtekenreeks voor verbeterde beveiliging en vereist dat u uw service bijwerkt om deze uitgebreide handtekening te gebruiken.

  • Gedeelde sleutel voor Table Service. Gebruik het autorisatieschema voor gedeelde sleutels om aanvragen uit te voeren voor de Table-service met behulp van de REST API. Autorisatie van gedeelde sleutels voor de Table-service in versie 2009-09-19 en hoger gebruikt dezelfde handtekeningtekenreeks als in eerdere versies van de Table-service.

  • Gedeelde Sleutel Lite. Gebruik het shared Key Lite-autorisatieschema om aanvragen te doen voor de blob-, wachtrij-, tabel- en bestandsservices. Shared Key Lite wordt niet ondersteund voor premium-pagina-blobs.

    Voor versie 2009-09-19 en hoger van de Blob- en Queue-services ondersteunt Shared Key Lite-autorisatie het gebruik van een handtekeningtekenreeks die identiek is aan wat werd ondersteund ten opzichte van gedeelde sleutel in eerdere versies van de Blob- en Queue-services. U kunt daarom Shared Key Lite gebruiken om aanvragen te doen voor de Blob- en Queue-services zonder uw handtekeningtekenreeks bij te werken.

Voor een geautoriseerde aanvraag zijn twee headers vereist: de Date- of x-ms-date-header en de Authorization-header. In de volgende secties wordt beschreven hoe u deze headers samen kunt stellen.

Belangrijk

Azure Storage biedt ondersteuning voor ZOWEL HTTP als HTTPS, maar het gebruik van HTTPS wordt ten zeerste aanbevolen.

Notitie

Een container of blob kan beschikbaar worden gesteld voor openbare toegang door de machtigingen van een container in te stellen. Zie Toegang tot Azure Storage-resources beherenvoor meer informatie. Een container, blob, wachtrij of tabel kan beschikbaar worden gesteld voor ondertekende toegang via een handtekening voor gedeelde toegang; een handtekening voor gedeelde toegang wordt geautoriseerd via een ander mechanisme. Zie Toegang delegeren met een handtekening voor gedeelde toegang voor meer informatie.

De datumkoptekst opgeven

Alle geautoriseerde aanvragen moeten de UTC-tijdstempel (Coordinated Universal Time) voor de aanvraag bevatten. U kunt de tijdstempel opgeven in de x-ms-date header of in de standaard-HTTP/HTTPS-Date-header. Als beide headers zijn opgegeven voor de aanvraag, wordt de waarde van x-ms-date gebruikt als het moment van maken van de aanvraag.

De opslagservices zorgen ervoor dat een aanvraag niet ouder is dan 15 minuten op het moment dat deze de service bereikt. Dit beschermt tegen bepaalde beveiligingsaanvallen, waaronder herhalingsaanvallen. Wanneer deze controle mislukt, retourneert de server antwoordcode 403 (Verboden).

Notitie

De x-ms-date header wordt geleverd omdat sommige HTTP-clientbibliotheken en proxy's de Date-header automatisch instellen en de ontwikkelaar niet de mogelijkheid geven om de waarde ervan te lezen om deze op te nemen in de geautoriseerde aanvraag. Als u x-ms-dateinstelt, maakt u de handtekening met een lege waarde voor de Date header.

De autorisatieheader opgeven

Een geautoriseerde aanvraag moet de Authorization header bevatten. Als deze header niet is opgenomen, is de aanvraag anoniem en slaagt deze alleen voor een container of blob die is gemarkeerd voor openbare toegang, of voor een container, blob, wachtrij of tabel waarvoor een handtekening voor gedeelde toegang is opgegeven voor gedelegeerde toegang.

Als u een aanvraag wilt autoriseren, moet u de aanvraag ondertekenen met de sleutel voor het account dat de aanvraag doet en die handtekening doorgeven als onderdeel van de aanvraag.

De indeling voor de Authorization header is als volgt:

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

waarbij SharedKey of SharedKeyLite de naam van het autorisatieschema is, is AccountName de naam van het account dat de resource aanvraagt en Signature een HMAC (Hash-based Message Authentication Code) is die is samengesteld uit de aanvraag en wordt berekend met behulp van het SHA256-algoritme en vervolgens gecodeerd met behulp van Base64-codering.

Notitie

Het is mogelijk om een resource aan te vragen die zich onder een ander account bevindt, als die resource openbaar toegankelijk is.

In de volgende secties wordt beschreven hoe u de Authorization header maakt.

De tekenreeks voor de handtekening samenstellen

Hoe u de handtekeningtekenreeks maakt, is afhankelijk van welke service en versie u autoriseert en welk autorisatieschema u gebruikt. Houd rekening met het volgende bij het maken van de tekenreeks:

  • Het WERKWOORD-gedeelte van de tekenreeks is het HTTP-werkwoord, zoals GET of PUT, en moet hoofdletters bevatten.

  • Voor autorisatie van gedeelde sleutels voor de blob-, wachtrij- en bestandsservices kan elke header die is opgenomen in de handtekeningtekenreeks slechts één keer worden weergegeven. Als er een header wordt gedupliceerd, retourneert de service statuscode 400 (Ongeldige aanvraag).

  • De waarden van alle standaard HTTP-headers moeten worden opgenomen in de tekenreeks in de volgorde die wordt weergegeven in de handtekeningindeling, zonder de headernamen. Deze headers kunnen leeg zijn als ze niet worden opgegeven als onderdeel van de aanvraag; in dat geval is alleen het nieuwe regelteken vereist.

  • Als de x-ms-date koptekst is opgegeven, kunt u de Date koptekst negeren, ongeacht of deze is opgegeven in de aanvraag en gewoon een lege regel opgeven voor het Date gedeelte van de handtekeningtekenreeks. In dit geval volgt u de instructies in de De tekenreeks voor canonicaliseerde headers sectie samenstellen om de x-ms-date koptekst toe te voegen.

    Het is aanvaardbaar om zowel x-ms-date als Dateop te geven; in dit geval gebruikt de service de waarde van x-ms-date.

  • Als de x-ms-date koptekst niet is opgegeven, geeft u de Date koptekst op in de handtekeningtekenreeks, zonder de naam van de koptekst op te geven.

  • Alle nieuwe regeltekens (\n) die worden weergegeven, zijn vereist in de handtekeningtekenreeks.

  • De tekenreeks bevat canonieke headers en canonicaliseerde resourcereeksen. Als u deze tekenreeksen canoniseert, worden ze in een standaardindeling opgenomen die wordt herkend door Azure Storage. Zie de juiste secties verderop in dit onderwerp voor gedetailleerde informatie over het samenstellen van de CanonicalizedHeaders en CanonicalizedResource tekenreeksen waaruit een deel bestaat.

Blob-, wachtrij- en bestandsservices (autorisatie voor gedeelde sleutels)

Als u de handtekeningtekenreeks voor gedeelde sleutels wilt coderen voor een aanvraag op basis van de versie 2009-09-19 en hoger van de Blob- of Queue-service, en versie 2014-02-14 en hoger van de File-service, gebruikt u de volgende indeling:

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;

Belangrijk

In de huidige versie moet het veld Content-Length een lege tekenreeks zijn als de inhoudslengte van de aanvraag nul is. In versie 2014-02-14 en eerder is de inhoudslengte opgenomen, zelfs als nul. Zie hieronder voor meer informatie over het oude gedrag.

In het volgende voorbeeld ziet u een tekenreeks voor een Blob ophalen bewerking. Als er geen headerwaarde is, wordt alleen het nieuwe-regelteken opgegeven.

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

Als u deze regel per regel opsplitst, wordt elk gedeelte van dezelfde tekenreeks weergegeven:

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*/

Codeer deze tekenreeks vervolgens met behulp van het HMAC-SHA256-algoritme over de handtekeningtekenreeks met UTF-8-codering, maak de Authorization header en voeg de header toe aan de aanvraag. In het volgende voorbeeld ziet u de Authorization header voor dezelfde bewerking:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Als u shared key authorization wilt gebruiken met versie 2009-09-19 en hoger van de Blob- en Queue-services, moet u uw code bijwerken om deze uitgebreide handtekeningtekenreeks te gebruiken.

Als u uw code liever migreert naar versie 2009-09-19 of hoger van de Blob- en Queue-services met de minste mogelijke wijzigingen, kunt u uw bestaande Authorization headers wijzigen om Shared Key Lite te gebruiken in plaats van gedeelde sleutel. De handtekeningindeling die door Shared Key Lite is vereist, is identiek aan de indeling die vereist is voor Gedeelde sleutel door versies van de Blob- en Queue-services vóór 2009-09-19.

Belangrijk

Als u toegang hebt tot de secundaire locatie in een opslagaccount waarvoor geo-replicatie met leestoegang (RA-GRS) is ingeschakeld, neemt u de -secondary aanduiding niet op in de autorisatieheader. Voor autorisatiedoeleinden is de accountnaam altijd de naam van de primaire locatie, zelfs voor secundaire toegang.

Content-Length-header in versie 2014-02-14 en eerder

Als u versie 2014-02-14 of eerder gebruikt, stelt u als Content-Length nul is, het Content-Length deel van de StringToSign in op 0. Normaal gesproken is dit een lege tekenreeks.

Voor de volgende aanvraag wordt bijvoorbeeld de waarde van de Content-Length header opgenomen in de StringToSign zelfs als deze nul is.

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

De StringToSign wordt als volgt samengesteld:

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

Overwegende dat in versies na 2014-02-14 de StringToSign een lege tekenreeks voor Content-Lengthmoet bevatten:

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

Table-service (autorisatie voor gedeelde sleutels)

U moet autorisatie voor gedeelde sleutels gebruiken om een aanvraag voor de Table-service te autoriseren als uw service de REST API gebruikt om de aanvraag te doen. De indeling van de tekenreeks voor gedeelde sleutel voor de tabelservice is hetzelfde voor alle versies.

De tekenreeks voor handtekening voor gedeelde sleutels voor een aanvraag voor de Tabelservice verschilt enigszins van die voor een aanvraag voor de Blob- of Queue-service, omdat deze geen CanonicalizedHeaders gedeelte van de tekenreeks bevat. Bovendien is de Date header in dit geval nooit leeg, zelfs als de aanvraag de x-ms-date-header instelt. Als de aanvraag x-ms-dateinstelt, wordt die waarde ook gebruikt voor de waarde van de Date-header.

Als u de tekenreeks voor een aanvraag wilt coderen voor de Table-service die is gemaakt met behulp van de REST API, gebruikt u de volgende indeling:

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

Notitie

Vanaf versie 2009-09-19 vereist de Table-service dat alle REST-aanroepen de DataServiceVersion en MaxDataServiceVersion headers bevatten. Zie De headers van de OData Data Service-versie instellen voor meer informatie.

Blob-, Wachtrij- en Bestandsservices (shared Key Lite-autorisatie)

U kunt shared Key Lite-autorisatie gebruiken om een aanvraag te autoriseren op basis van de versie 2009-09-19 en hoger van de Blob- en Queue-services, en versie 2014-02-14 en hoger van de bestandsservices. Shared Key Lite wordt niet ondersteund voor premium-pagina-blobs.

De handtekeningtekenreeks voor Shared Key Lite is identiek aan de handtekeningtekenreeks die is vereist voor autorisatie van gedeelde sleutels in versies van de Blob- en Queue-services vóór 2009-09-19. Dus als u uw code wilt migreren met het minste aantal wijzigingen in versie 2009-09-19 van de Blob- en Queue-services, kunt u uw code wijzigen om Shared Key Lite te gebruiken, zonder de tekenreeks zelf te wijzigen. Door Shared Key Lite te gebruiken, krijgt u niet de verbeterde beveiligingsfunctionaliteit die wordt geboden met gedeelde sleutel met versie 2009-09-19 en hoger.

Als u de tekenreeks voor een aanvraag wilt coderen voor de Blob- of Queue-service, gebruikt u de volgende indeling:

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

In het volgende voorbeeld ziet u een tekenreeks voor een Put Blob bewerking. Houd er rekening mee dat de headerregel Content-MD5 leeg is. De headers in de tekenreeks zijn naam-waardeparen die aangepaste metagegevenswaarden voor de nieuwe blob opgeven.

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

Codeer deze tekenreeks vervolgens met behulp van het HMAC-SHA256-algoritme over de handtekeningtekenreeks met UTF-8-codering, maak de Authorization header en voeg de header toe aan de aanvraag. In het volgende voorbeeld ziet u de Authorization header voor dezelfde bewerking:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Table-service (Shared Key Lite-autorisatie)

U kunt shared Key Lite-autorisatie gebruiken om een aanvraag te autoriseren voor elke versie van de Table-service.

Als u de tekenreeks voor een aanvraag wilt coderen voor de Table-service met behulp van Shared Key Lite, gebruikt u de volgende indeling:

StringToSign = Date + "\n"
               CanonicalizedResource

In het volgende voorbeeld ziet u een tekenreeks voor een tabel maken bewerking.

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

Codeer vervolgens deze tekenreeks met behulp van het HMAC-SHA256-algoritme, maak de Authorization header en voeg vervolgens de header toe aan de aanvraag. In het volgende voorbeeld ziet u de Authorization header voor dezelfde bewerking:

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

De tekenreeks voor canonicalized headers samenstellen

Voer de volgende stappen uit om het CanonicalizedHeaders gedeelte van de handtekeningtekenreeks samen te stellen:

  1. Haal alle headers op voor de resource die beginnen met x-ms-, inclusief de x-ms-date-header.

  2. Converteer elke HTTP-headernaam naar kleine letters.

  3. Sorteer de kopteksten lexicografisch op kopnaam, in oplopende volgorde. Elke koptekst kan slechts één keer in de tekenreeks worden weergegeven.

    Notitie

    Lexicografische volgorde valt mogelijk niet altijd samen met conventionele alfabetische volgorde.

  4. Vervang elke lineaire witruimte in de headerwaarde door één spatie.

Lineaire witruimte omvat regelterugloop/regelinvoer (CRLF), spaties en tabs. Zie RFC 2616, sectie 4.2 voor meer informatie. Vervang geen witruimte in een tekenreeks tussen aanhalingstekens.

  1. Eventuele witruimte rond de dubbele punt in de koptekst knippen.

  2. Voeg ten slotte een nieuw regelteken toe aan elke canonieke koptekst in de resulterende lijst. Maak de CanonicalizedHeaders tekenreeks door alle headers in deze lijst samen te voegen in één tekenreeks.

Hieronder ziet u een voorbeeld van een tekenreeks met canonieke headers:

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

Notitie

Vóór serviceversie 2016-05-31 werden headers met lege waarden weggelaten uit de handtekeningtekenreeks. Deze worden nu weergegeven in CanonicalizedHeaders door direct na het dubbele punt met het afsluitpunt nieuwe regel te volgen.

De canonicaliseerde resourcetekenreeks samenstellen

Het CanonicalizedResource deel van de handtekeningtekenreeks vertegenwoordigt de opslagservicesresource waarop de aanvraag is gericht. Elk gedeelte van de CanonicalizedResource tekenreeks die is afgeleid van de URI van de resource, moet exact worden gecodeerd zoals deze zich in de URI bevindt.

Er zijn twee ondersteunde indelingen voor de CanonicalizedResource tekenreeks:

  • Een indeling die ondersteuning biedt voor autorisatie van gedeelde sleutels voor versie 2009-09-19 en hoger van de Blob- en Queue-services, en voor versie 2014-02-14 en hoger van de Bestandsservice.

  • Een indeling die ondersteuning biedt voor Shared Key en Shared Key Lite voor alle versies van de Table-service en Shared Key Lite voor versie 2009-09-19 en hoger van de Blob- en Queue-services. Deze indeling is identiek aan de indeling die wordt gebruikt met eerdere versies van de opslagservices.

Zie een van de volgende onderwerpen voor hulp bij het samenstellen van de URI voor de resource die u gebruikt:

Belangrijk

Als uw opslagaccount wordt gerepliceerd met geo-replicatie met leestoegang (RA-GRS) en u toegang hebt tot een resource op de secundaire locatie, neemt u de –secondary aanduiding niet op in de CanonicalizedResource tekenreeks. De resource-URI die wordt gebruikt in de CanonicalizedResource tekenreeks-URI moet de URI van de resource op de primaire locatie zijn.

Notitie

Als u zich autoriseert voor de opslagemulator, wordt de accountnaam twee keer weergegeven in de CanonicalizedResource tekenreeks. Dit wordt verwacht. Als u zich autoriseert voor Azure-opslagservices, wordt de accountnaam slechts één keer weergegeven in de CanonicalizedResource tekenreeks.

Indeling gedeelde sleutel voor 2009-09-19 en hoger

Deze indeling ondersteunt autorisatie van gedeelde sleutels voor de versie 2009-09-19 en hoger van de blob- en wachtrijservices, en de versie 2014-02-14 en hoger van de bestandsservices. Maak de CanonicalizedResource tekenreeks als volgt in deze indeling:

  1. Begin met een lege tekenreeks (""), voeg een slash (/) toe, gevolgd door de naam van het account dat eigenaar is van de resource die wordt geopend.

  2. Voeg het gecodeerde URI-pad van de resource toe zonder queryparameters.

  3. Haal alle queryparameters op de resource-URI op, inclusief de comp parameter als deze bestaat.

  4. Converteer alle parameternamen naar kleine letters.

  5. Sorteer de queryparameters lexicografisch op parameternaam, in oplopende volgorde.

  6. URL-decodeer elke naam en waarde van de queryparameter.

  7. Neem vóór elk naam-waardepaar een nieuw regelteken (\n) op.

  8. Voeg elke naam en waarde van de queryparameter toe aan de tekenreeks in de volgende indeling en zorg ervoor dat u de dubbele punt (:) tussen de naam en de waarde opneemt:

    parameter-name:parameter-value

  9. Als een queryparameter meer dan één waarde heeft, sorteert u alle waarden lexicografisch en neemt u deze op in een door komma's gescheiden lijst:

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

Houd rekening met de volgende regels voor het maken van de canonieke resourcetekenreeks:

  • Vermijd het gebruik van het nieuwe-regelteken (\n) in waarden voor queryparameters. Als deze moet worden gebruikt, moet u ervoor zorgen dat deze niet van invloed is op de indeling van de canonieke resourcetekenreeks.

  • Vermijd het gebruik van komma's in queryparameterwaarden.

Hier volgen enkele voorbeelden die het CanonicalizedResource gedeelte van de handtekeningtekenreeks weergeven, omdat deze kan worden samengesteld vanuit een bepaalde aanvraag-URI:

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

Shared Key Lite en Table-serviceindeling voor 2009-09-19 en hoger

Deze indeling ondersteunt Shared Key en Shared Key Lite voor alle versies van de Table-service en Shared Key Lite voor versie 2009-09-19 en hoger van de Blob- en Queue-services en versie 2014-02-14 en hoger van de Bestandsservice. Deze indeling is identiek aan de indeling die wordt gebruikt met eerdere versies van de opslagservices. Maak de CanonicalizedResource tekenreeks als volgt in deze indeling:

  1. Begin met een lege tekenreeks (""), voeg een slash (/) toe, gevolgd door de naam van het account dat eigenaar is van de resource die wordt geopend.

  2. Voeg het gecodeerde URI-pad van de resource toe. Als de aanvraag-URI een onderdeel van de resource adresseert, voegt u de juiste querytekenreeks toe. De querytekenreeks moet het vraagteken en de parameter comp bevatten (bijvoorbeeld ?comp=metadata). Er mogen geen andere parameters worden opgenomen in de querytekenreeks.

De handtekening coderen

Als u de handtekening wilt coderen, roept u het HMAC-SHA256 algoritme aan op de UTF-8-gecodeerde handtekeningtekenreeks en codeert u het resultaat als Base64. Houd er rekening mee dat u uw opslagaccountsleutel ook moet decoderen met Base64. Gebruik de volgende indeling (weergegeven als pseudocode):

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

Zie ook