Autoriseren met gedeelde sleutelAuthorize with Shared Key

Elk verzoek tegen een opslagservice moet worden geautoriseerd, tenzij het verzoek is voor een blob- of containerbron die beschikbaar is gesteld voor openbare of ondertekende toegang.Every request made against a storage service must be authorized, unless the request is for a blob or container resource that has been made available for public or signed access. Een optie voor het toestaan van een aanvraag is door gedeelde sleutel te gebruiken, beschreven in dit artikel.One option for authorizing a request is by using Shared Key, described in this article.

Tip

Azure Storage ondersteunt integratie met Azure Active Directory voor fijnmazige controle over toegang tot opslagbronnen.Azure Storage supports integration with Azure Active Directory for fine-grained control over access to storage resources. Azure AD-integratie wordt ondersteund voor de blob- en wachtrijservices.Azure AD integration is supported for the Blob and Queue services. Omdat Azure AD identiteitsbeheer biedt, u toegang tot opslagbronnen autoriseren zonder uw accounttoegangssleutels in uw toepassingen op te slaan, zoals u doet met Shared Key.Because Azure AD provides identity management, you can authorize access to storage resources without storing your account access keys in your applications, as you do with Shared Key. Zie Autoriseren met Azure Active Directoryvoor meer informatie.For more information, see Authorize with Azure Active Directory.

De ondersteunings-, wachtrij-, tabel- en bestandsservices 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):The Blob, Queue, Table, and File services support the following Shared Key authorization schemes for version 2009-09-19 and later (for Blob, Queue, and Table service) and version 2014-02-14 and later (for File service):

  • Gedeelde sleutel voor Blob-, queue- en bestandsservices.Shared Key for Blob, Queue, and File Services. Gebruik het autorisatieschema Gedeelde sleutel om aanvragen in te dienen tegen de blob-, wachtrij- en bestandsservices.Use the Shared Key authorization scheme to make requests against the Blob, Queue, and File services. Gedeelde sleutelautorisatie in versie 2009-09-19 en ondersteunt later een uitgebreide handtekeningreeks voor verbeterde beveiliging en vereist dat u uw service bijwerkt om deze uitgebreide handtekening te autoriseren.Shared Key authorization in version 2009-09-19 and later supports an augmented signature string for enhanced security and requires that you update your service to authorize using this augmented signature.

  • Gedeelde sleutel voor tafelservice.Shared Key for Table Service. Gebruik het autorisatieschema Gedeelde sleutel om aanvragen in te dienen tegen de tabelservice met behulp van de REST-API.Use the Shared Key authorization scheme to make requests against the Table service using the REST API. Gedeelde sleutelautorisatie voor de tabelservice in versie 2009-09-19 en gebruikt later dezelfde handtekeningtekenreeks als in eerdere versies van de tabelservice.Shared Key authorization for the Table service in version 2009-09-19 and later uses the same signature string as in previous versions of the Table service.

  • Gedeelde Key Lite.Shared Key Lite. Gebruik het autorisatieschema Voor Gedeelde Sleutel lite om aanvragen in te dienen tegen de services Blob, Queue, Table en File.Use the Shared Key Lite authorization scheme to make requests against the Blob, Queue, Table, and File services.

    Voor versie 2009-09-19 en hoger van de Blob- en Queue-services ondersteunt de machtiging Shared Key Lite 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.For version 2009-09-19 and later of the Blob and Queue services, Shared Key Lite authorization supports using a signature string identical to what was supported against Shared Key in previous versions of the Blob and Queue services. U daarom Shared Key Lite gebruiken om aanvragen in te dienen tegen de Blob- en Queue-services zonder uw handtekeningtekenreeks bij te werken.You can therefore use Shared Key Lite to make requests against the Blob and Queue services without updating your signature string.

Een geautoriseerde aanvraag vereist twee Date kopteksten: de of x-ms-date header en de Authorization header.An authorized request requires two headers: the Date or x-ms-date header and the Authorization header. In de volgende secties wordt beschreven hoe u deze kopteksten maakt.The following sections describe how to construct these headers.

Belangrijk

Azure Storage ondersteunt zowel HTTP als HTTPS, maar het gebruik van HTTPS is een aanrader.Azure Storage support both HTTP and HTTPS, but using HTTPS is highly recommended.

Notitie

Een container of blob kan beschikbaar worden gesteld voor openbare toegang door de machtigingen van een container in te stellen.A container or blob may be made available for public access by setting a container's permissions. Zie Toegang tot Azure Storage Resources beherenvoor meer informatie .For more information, see Manage Access to Azure Storage Resources. Een container, blob, wachtrij of tabel is mogelijk beschikbaar voor ondertekende toegang via een handtekening met gedeelde toegang. een gedeelde toegangshandtekening is geautoriseerd via een ander mechanisme.A container, blob, queue, or table may be available for signed access via a shared access signature; a shared access signature is authorized through a different mechanism. Zie Toegang tot gemachtigden met een handtekening voor gedeelde toegang voor meer informatie.See Delegate access with a shared access signature for more details.

De kopdatum Datum opgevenSpecifying the Date header

Alle geautoriseerde aanvragen moeten de timestamp van de gecoördineerde universele tijd (UTC) voor de aanvraag bevatten.All authorized requests must include the Coordinated Universal Time (UTC) timestamp for the request. U de tijdstempel x-ms-date opgeven in de koptekst Date of in de standaard HTTP/HTTPS-header.You can specify the timestamp either in the x-ms-date header, or in the standard HTTP/HTTPS Date header. Als beide kopteksten op de aanvraag x-ms-date zijn opgegeven, wordt de waarde van het verzoek gebruikt als het tijd van het maken van de aanvraag.If both headers are specified on the request, the value of x-ms-date is used as the request's time of creation.

De opslagservices zorgen ervoor dat een aanvraag niet ouder is dan 15 minuten tegen de tijd dat de service is bereikt.The storage services ensure that a request is no older than 15 minutes by the time it reaches the service. Dit beschermt tegen bepaalde veiligheidsaanvallen, waaronder replay-aanvallen.This guards against certain security attacks, including replay attacks. Wanneer deze controle mislukt, retourneert de server responscode 403 (Verboden).When this check fails, the server returns response code 403 (Forbidden).

Notitie

De x-ms-date header wordt geleverd omdat sommige HTTP-clientbibliotheken en Date proxy's automatisch de koptekst instellen en de ontwikkelaar niet de mogelijkheid geven om de waarde ervan te lezen om deze in de geautoriseerde aanvraag op te nemen.The x-ms-date header is provided because some HTTP client libraries and proxies automatically set the Date header, and do not give the developer an opportunity to read its value in order to include it in the authorized request. Als u x-ms-datede handtekening instelt met Date een lege waarde voor de koptekst.If you set x-ms-date, construct the signature with an empty value for the Date header.

De kopautorisatie opgevenSpecifying the Authorization header

Een geautoriseerde aanvraag moet Authorization de koptekst bevatten.An authorized request must include the Authorization header. Als deze koptekst niet is opgenomen, is de aanvraag anoniem en kan deze alleen slagen voor een container of blob die is gemarkeerd voor openbare toegang, of tegen een container, blob, wachtrij of tabel waarvoor een handtekening met gedeelde toegang is opgegeven voor gedelegeerde toegang.If this header is not included, the request is anonymous and may only succeed against a container or blob that is marked for public access, or against a container, blob, queue, or table for which a shared access signature has been provided for delegated access.

Als u een aanvraag wilt autoriseren, moet u het verzoek ondertekenen met de sleutel voor het account dat het verzoek indient en die handtekening doorgeven als onderdeel van het verzoek.To authorize a request, you must sign the request with the key for the account that is making the request and pass that signature as part of the request.

De indeling Authorization voor de koptekst is als volgt:The format for the Authorization header is as follows:

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

waar SharedKey SharedKeyLite of is de naam AccountName van de autorisatie regeling, is de Signature naam van het account dat de bron, en is een Hash-based Message Authentication Code (HMAC) opgebouwd uit de aanvraag en berekend met behulp van de SHA256 algoritme, en vervolgens gecodeerd met behulp van Base64 codering.where SharedKey or SharedKeyLite is the name of the authorization scheme, AccountName is the name of the account requesting the resource, and Signature is a Hash-based Message Authentication Code (HMAC) constructed from the request and computed by using the SHA256 algorithm, and then encoded by using Base64 encoding.

Notitie

Het is mogelijk om een resource aan te vragen die zich onder een ander account bevindt, als die bron openbaar toegankelijk is.It is possible to request a resource that resides beneath a different account, if that resource is publicly accessible.

In de volgende secties Authorization wordt beschreven hoe u de koptekst construeren.The following sections describe how to construct the Authorization header.

De handtekeningtekenreeks construerenConstructing the signature string

Hoe u de handtekeningtekenreeks maakt, is afhankelijk van de service en versie die u autoschrijft en tegen welk autorisatieschema u deze gebruikt.How you construct the signature string depends on which service and version you are authorizing against and which authorization scheme you are using. Houd bij het construeren van de handtekeningtekenreeks rekening met het volgende:When constructing the signature string, keep in mind the following:

  • Het werkwoordgedeelte van de tekenreeks is het HTTP-werkwoord, zoals GET of PUT, en moet hoofdletters zijn.The VERB portion of the string is the HTTP verb, such as GET or PUT, and must be uppercase.

  • Voor de machtiging Voor gedeelde sleutels voor de blob-, wachtrij- en bestandsservices wordt elke koptekst in de handtekeningtekenreeks slechts één keer weergegeven.For Shared Key authorization for the Blob, Queue, and File services, each header included in the signature string may appear only once. Als een koptekst wordt gedupliceerd, retourneert de service statuscode 400 (Bad Request).If any header is duplicated, the service returns status code 400 (Bad Request).

  • De waarden van alle standaard HTTP-headers moeten worden opgenomen in de tekenreeks in de volgorde die wordt weergegeven in de handtekeningindeling, zonder de kopnamen.The values of all standard HTTP headers must be included in the string in the order shown in the signature format, without the header names. Deze kopteksten kunnen leeg zijn als ze niet als onderdeel van de aanvraag worden opgegeven; in dat geval is alleen het nieuwe regelteken vereist.These headers may be empty if they are not being specified as part of the request; in that case, only the new-line character is required.

  • Als x-ms-date de koptekst is opgegeven, u de Date koptekst negeren, ongeacht of deze op Date de aanvraag is opgegeven, en geeft u gewoon een lege regel op voor het gedeelte van de handtekeningtekenreeks.If the x-ms-date header is specified, you may ignore the Date header, regardless of whether it is specified on the request, and simply specify an empty line for the Date portion of the signature string. Volg in dit geval de instructies in de sectie De tekenreeks van x-ms-date canonicalized headers voor het toevoegen van de koptekst.In this case, follow the instructions in the Constructing the canonicalized headers string section for adding the x-ms-date header.

    Het is aanvaardbaar beide x-ms-date Datete specificeren en ; in dit geval gebruikt de x-ms-dateservice de waarde van .It is acceptable to specify both x-ms-date and Date; in this case, the service uses the value of x-ms-date.

  • Als x-ms-date de koptekst niet Date is opgegeven, geeft u de koptekst op in de tekenreeks, zonder de naam van de koptekst op te nemen.If the x-ms-date header is not specified, specify the Date header in the signature string, without including the header name.

  • Alle weergegeven nieuwe regeltekens (\n) zijn vereist in de handtekeningtekenreeks.All new-line characters (\n) shown are required within the signature string.

  • De handtekeningtekenreeks bevat canonicalized headers en canonicalized resource strings.The signature string includes canonicalized headers and canonicalized resource strings. Canonicalizing deze tekenreeksen zet ze in een standaardindeling die wordt herkend door Azure Storage.Canonicalizing these strings puts them into a standard format that is recognized by Azure Storage. Zie de juiste secties CanonicalizedHeaders CanonicalizedResource later in dit onderwerp voor gedetailleerde informatie over het samenstellen van de tekenreeksen die deel uitmaken van de handtekeningtekenreeks.For detailed information on constructing the CanonicalizedHeaders and CanonicalizedResource strings that make up part of the signature string, see the appropriate sections later in this topic.

Blob-, wachtrij- en bestandsservices (machtiging voor gedeelde sleutels)Blob, Queue, and File Services (Shared Key authorization)

Als u de handtekeningtekenreeks Gedeelde sleutel voor een aanvraag wilt coderen tegen de versie 2009-09-19 en later van de blob- of wachtrijservice en versie 2014-02-14 en later van de bestandsservice, gebruikt u de volgende indeling:To encode the Shared Key signature string for a request against the 2009-09-19 version and later of the Blob or Queue service, and version 2014-02-14 and later of the File service, use the following format:

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 Inhoudslengte een lege tekenreeks zijn als de inhoudslengte van de aanvraag nul is.In the current version, the Content-Length field must be an empty string if the content length of the request is zero. In versie 2014-02-14 en eerder werd de inhoudslengte opgenomen, zelfs als deze nul is.In version 2014-02-14 and earlier, the content length was included even if zero. Zie hieronder voor meer informatie over het oude gedrag.See below for more information on the old behavior.

In het volgende voorbeeld wordt een handtekeningtekenreeks weergegeven voor een Bewerking Blob opvoeren.The following example shows a signature string for a Get Blob operation. Wanneer er geen kopwaarde is, wordt alleen het teken van de nieuwe regel opgegeven.Where there is no header value, the new-line character only is specified.

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 voor regel opbreekt, wordt elk gedeelte van dezelfde tekenreeks weergegeven:Breaking this down line-by-line shows each portion of the same string:

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 vervolgens deze tekenreeks met het HMAC-SHA256-algoritme via de utf-8-gecodeerde handtekeningtekenreeks, construeert de Authorization koptekst en voeg de koptekst toe aan de aanvraag.Next, encode this string by using the HMAC-SHA256 algorithm over the UTF-8-encoded signature string, construct the Authorization header, and add the header to the request. In het volgende Authorization voorbeeld wordt de koptekst voor dezelfde bewerking weergegeven:The following example shows the Authorization header for the same operation:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Als u de machtiging Gedeelde sleutel wilt gebruiken met versie 2009-09-19 en later van de blob- en wachtrijservices, moet u uw code bijwerken om deze uitgebreide handtekeningtekenreeks te gebruiken.To use Shared Key authorization with version 2009-09-19 and later of the Blob and Queue services, you must update your code to use this augmented signature string.

Als u uw code liever migreert naar versie 2009-09-19 of hoger van de Blob- Authorization en Queue-services met de minste mogelijke wijzigingen, u uw bestaande headers wijzigen om Shared Key Lite te gebruiken in plaats van Gedeelde sleutel.If you prefer to migrate your code to version 2009-09-19 or later of the Blob and Queue services with the fewest possible changes, you can modify your existing Authorization headers to use Shared Key Lite instead of Shared Key. De handtekeningindeling die vereist is voor Shared Key Lite is identiek aan die van gedeelde sleutel door versies van de Blob- en Queue-services vóór 2009-09-19.The signature format required by Shared Key Lite is identical to that required for Shared Key by versions of the Blob and Queue services prior to 2009-09-19.

Belangrijk

Als u toegang hebt tot de secundaire locatie in een opslagaccount waarvoor geo-replicatie (READ-Access) is ingeschakeld, moet u de -secondary aanduiding niet opnemen in de autorisatiekoptekst.If you are accessing the secondary location in a storage account for which read-access geo-replication (RA-GRS) is enabled, do not include the -secondary designation in the authorization header. Voor autorisatiedoeleinden is de accountnaam altijd de naam van de primaire locatie, zelfs voor secundaire toegang.For authorization purposes, the account name is always the name of the primary location, even for secondary access.

Content-Length header in versie 2014-02-14 en eerderContent-Length header in version 2014-02-14 and earlier

Bij het gebruik van versie 2014-02-14 of eerder, Content-Length als het nul is, stelt u het Content-Length deel van de StringToSign . 0When using version 2014-02-14 or earlier, if Content-Length is zero, then set the Content-Length part of the StringToSign to 0. Normaal gesproken zou dit een lege string zijn.Normally this would be an empty string.

Voor de volgende aanvraag wordt bijvoorbeeld Content-Length de waarde van StringToSign de koptekst opgenomen in de zelfs wanneer deze nul is.For example, for the following request, the value of the Content-Length header is included in the StringToSign even when it is zero.

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 is als volgt gebouwd:The StringToSign is constructed as follows:

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 een StringToSign Content-Lengthlege snaar moet bevatten voor :Whereas in versions after to 2014-02-14, the StringToSign must contain an empty string for 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

Tabelservice (machtiging voor gedeelde sleutels)Table service (Shared Key authorization)

U moet de machtiging Gedeelde sleutel gebruiken om een aanvraag voor de tabelservice te autoriseren als uw service de REST-API gebruikt om de aanvraag in te dienen.You must use Shared Key authorization to authorize a request made against the Table service if your service is using the REST API to make the request. De indeling van de handtekeningtekenreeks voor Gedeelde sleutel ten opzichte van de tabelservice is voor alle versies hetzelfde.The format of the signature string for Shared Key against the Table service is the same for all versions.

De handtekeningtekenreeks Gedeelde sleutel voor een aanvraag tegen de tabelservice verschilt enigszins van die voor een aanvraag CanonicalizedHeaders ten opzichte van de blob- of wachtrijservice, omdat deze het gedeelte van de tekenreeks niet bevat.The Shared Key signature string for a request against the Table service differs slightly from that for a request against the Blob or Queue service, in that it does not include the CanonicalizedHeaders portion of the string. Bovendien is Date de koptekst in dit geval nooit x-ms-date leeg, zelfs niet als de aanvraag de koptekst instelt.Additionally, the Date header in this case is never empty even if the request sets the x-ms-date header. Als de x-ms-dateaanvraag wordt ingesteld, wordt die Date waarde ook gebruikt voor de waarde van de koptekst.If the request sets x-ms-date, that value is also used for the value of the Date header.

Als u de handtekeningtekenreeks voor een aanvraag wilt coderen tegen de tabelservice die is gemaakt met de REST-API, gebruikt u de volgende indeling:To encode the signature string for a request against the Table service made using the REST API, use the following format:

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

Notitie

Vanaf versie 2009-09-19 vereist de tabelservice dat DataServiceVersion alle MaxDataServiceVersion REST-aanroepen de kopteksten en kopteksten bevatten.Beginning with version 2009-09-19, the Table service requires that all REST calls include the DataServiceVersion and MaxDataServiceVersion headers. Zie De versiekoppen van de OData Data Service-service instellen voor meer informatie.See Setting the OData Data Service Version Headers for more information.

Blob-, wachtrij- en bestandsservices (machtiging voor gedeelde sleutellite)Blob, Queue, and File services (Shared Key Lite authorization)

U de machtiging Gedeelde Sleutel lite gebruiken om een aanvraag te autoriseren die is gedaan tegen de versie 2009-09-19 en later van de Blob- en Queue-services en versie 2014-02-14 en hoger van de bestandsservices.You may use Shared Key Lite authorization to authorize a request made against the 2009-09-19 version and later of the Blob and Queue services, and version 2014-02-14 and later of the File services.

De handtekeningtekenreeks voor Shared Key Lite is identiek aan de handtekeningtekenreeks die vereist is voor de machtiging Gedeelde sleutel in versies van de blob- en wachtrijservices vóór 2009-09-19.The signature string for Shared Key Lite is identical to the signature string required for Shared Key authorization in versions of the Blob and Queue services prior to 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, u uw code wijzigen om Shared Key Lite te gebruiken, zonder de handtekeningtekenreeks zelf te wijzigen.So if you wish to migrate your code with the least number of changes to version 2009-09-19 of the Blob and Queue services, you can modify your code to use Shared Key Lite, without changing the signature string itself. Door Shared Key Lite te gebruiken, krijgt u niet de verbeterde beveiligingsfunctionaliteit die wordt geboden door Shared Key te gebruiken met versie 2009-09-19 en hoger.By using Shared Key Lite, you will not gain the enhanced security functionality provided by using Shared Key with version 2009-09-19 and later.

Als u de handtekeningtekenreeks voor een aanvraag wilt coderen tegen de blob- of wachtrijservice, gebruikt u de volgende indeling:To encode the signature string for a request against the Blob or Queue service, use the following format:

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

In het volgende voorbeeld ziet u een handtekeningtekenreeks voor een bewerking Put Blob.The following example shows a signature string for a Put Blob operation. Houd er rekening mee dat de koptekstregel Content-MD5 leeg is.Note that the Content-MD5 header line is empty. De kopteksten in de tekenreeks zijn naam-waardeparen die aangepaste metagegevenswaarden voor de nieuwe blob opgeven.The headers shown in the string are name-value pairs that specify custom metadata values for the new 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  

Codeer vervolgens deze tekenreeks met het HMAC-SHA256-algoritme via de utf-8-gecodeerde handtekeningtekenreeks, construeert de Authorization koptekst en voeg de koptekst toe aan de aanvraag.Next, encode this string by using the HMAC-SHA256 algorithm over the UTF-8-encoded signature string, construct the Authorization header, and add the header to the request. In het volgende Authorization voorbeeld wordt de koptekst voor dezelfde bewerking weergegeven:The following example shows the Authorization header for the same operation:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Tabelservice (machtiging voor Gedeelde Sleutel lite)Table service (Shared Key Lite authorization)

U de machtiging Shared Key Lite gebruiken om een aanvraag te autoriseren die is gedaan tegen elke versie van de Tabelservice.You can use Shared Key Lite authorization to authorize a request made against any version of the Table service.

Als u de handtekeningtekenreeks voor een aanvraag voor een aanvraag tegen de tabelservice met Shared Key Lite wilt coderen, gebruikt u de volgende indeling:To encode the signature string for a request against the Table service using Shared Key Lite, use the following format:

StringToSign = Date + "\n"
               CanonicalizedResource  

In het volgende voorbeeld wordt een handtekeningtekenreeks weergegeven voor een bewerking Tabel maken.The following example shows a signature string for a Create Table operation.

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

Codeer vervolgens deze tekenreeks met het HMAC-SHA256-algoritme, construeert de Authorization koptekst en voeg vervolgens de koptekst toe aan de aanvraag.Next, encode this string by using the HMAC-SHA256 algorithm, construct the Authorization header, and then add the header to the request. In het volgende Authorization voorbeeld wordt de koptekst voor dezelfde bewerking weergegeven:The following example shows the Authorization header for the same operation:

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

De tekenreeks canonicalized headers construerenConstructing the canonicalized headers string

Voer de CanonicalizedHeaders volgende stappen uit om het gedeelte van de handtekeningtekenreeks te construeren:To construct the CanonicalizedHeaders portion of the signature string, follow these steps:

  1. Haal alle kopteksten op x-ms-voor de x-ms-date resource die beginnen met , inclusief de koptekst.Retrieve all headers for the resource that begin with x-ms-, including the x-ms-date header.

  2. Converteer elke HTTP-koptekstnaam naar kleine letters.Convert each HTTP header name to lowercase.

  3. Sorteer de kopteksten lexicographically op koptekstnaam, in oplopende volgorde.Sort the headers lexicographically by header name, in ascending order. Elke koptekst mag slechts één keer in de tekenreeks worden weergegeven.Each header may appear only once in the string.

    Notitie

    Lexicografische volgorde kan niet altijd samenvallen met conventionele alfabetische volgorde.Lexicographical ordering may not always coincide with conventional alphabetical ordering.

  4. Vervang een lineaire witruimte in de kopwaarde door één spatie.Replace any linear whitespace in the header value with a single space.

Lineaire witruimte omvat vervoer retour / lijn feed (CRLF), spaties, en tabbladen.Linear whitespace includes carriage return/line feed (CRLF), spaces, and tabs. Zie RFC 2616, punt 4.2 voor meer informatie.See RFC 2616, section 4.2 for details. Vervang geen witruimte in een geciteerde tekenreeks.Do not replace any whitespace inside a quoted string.

  1. Knip eventuele witruimte rond de dubbele punt in de kop.Trim any whitespace around the colon in the header.

  2. Tot slot een nieuw regelteken toevoegen aan elke canonicalized header in de resulterende lijst.Finally, append a new-line character to each canonicalized header in the resulting list. Bouw CanonicalizedHeaders de tekenreeks door alle kopteksten in deze lijst in één tekenreeks te plaatsen.Construct the CanonicalizedHeaders string by concatenating all headers in this list into a single string.

Het volgende toont een voorbeeld van een canonicalized headers string:The following shows an example of a canonicalized headers string:

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

Notitie

Voorafgaand aan de serviceversie 2016-05-31 werden kopteksten met lege waarden weggelaten uit de handtekeningtekenreeks.Prior to service version 2016-05-31, headers with empty values were omitted from the signature string. Deze worden nu vertegenwoordigd in CanonicalizedHeaders door onmiddellijk na het dubbele puntkarakter met de eindigende nieuwe lijn te volgen.These are now represented in CanonicalizedHeaders by immediately following the colon character with the terminating new-line.

De tekenreeks canonicalized resource construerenConstructing the canonicalized resource string

Het CanonicalizedResource deel van de tekenreeks voor handtekeningen vertegenwoordigt de bron voor opslagservices waarop de aanvraag is gericht.The CanonicalizedResource part of the signature string represents the storage services resource targeted by the request. Elk deel CanonicalizedResource van de tekenreeks dat is afgeleid van de URI van de resource moet precies worden gecodeerd zoals het is in de URI.Any portion of the CanonicalizedResource string that is derived from the resource's URI should be encoded exactly as it is in the URI.

Er zijn twee ondersteunde CanonicalizedResource indelingen voor de tekenreeks:There are two supported formats for the CanonicalizedResource string:

  • Een indeling die de machtiging Gedeelde sleutel ondersteunt voor versie 2009-09-19 en hoger van de blob- en wachtrijservices en voor versie 2014-02-14 en hoger van de bestandsservice.A format that supports Shared Key authorization for version 2009-09-19 and later of the Blob and Queue services, and for version 2014-02-14 and later of the File service.

  • Een indeling die Shared Key en Shared Key Lite ondersteunt voor alle versies van de Table-service en Shared Key Lite voor versie 2009-09-19 en hoger van de Blob- en Queue-services.A format that supports Shared Key and Shared Key Lite for all versions of the Table service, and Shared Key Lite for version 2009-09-19 and later of the Blob and Queue services. Deze indeling is identiek aan die van eerdere versies van de opslagservices.This format is identical to that used with previous versions of the storage services.

Zie een van de volgende onderwerpen voor hulp bij het samenstellen van de URI voor de resource die u gebruikt:For help constructing the URI for the resource you are accessing, see one of the following topics:

Belangrijk

Als uw opslagaccount is gerepliceerd met georeplicatie (Read-Access Geo-replicatie) en u toegang hebt tot –secondary een bron CanonicalizedResource op de secundaire locatie, moet u de aanduiding niet opnemen in de tekenreeks.If your storage account is replicated with read-access geo-replication (RA-GRS), and you are accessing a resource in the secondary location, do not include the –secondary designation in the CanonicalizedResource string. De resource URI CanonicalizedResource die wordt gebruikt in de tekenreeks URI moet de URI van de resource op de primaire locatie zijn.The resource URI used in the CanonicalizedResource string URI should be the URI of the resource at the primary location.

Notitie

Als u toestemming geeft voor de opslagemulator, wordt CanonicalizedResource de accountnaam twee keer in de tekenreeks weergegeven.If you are authorizing against the storage emulator, the account name will appear twice in the CanonicalizedResource string. Dit is normaal gedrag.This is expected. Als u toestemming geeft voor Azure-opslagservices, wordt de CanonicalizedResource accountnaam slechts één keer weergegeven in de tekenreeks.If you are authorizing against Azure storage services, the account name will appear only one time in the CanonicalizedResource string.

Indeling gedeelde sleutel voor 2009-09-19 en laterShared Key format for 2009-09-19 and later

Deze indeling ondersteunt de machtiging Gedeelde sleutel voor de versie 2009-09-19 en later van de blob- en wachtrijservices en de versie 2014-02-14 en later van de bestandsservices.This format supports Shared Key authorization for the 2009-09-19 version and later of the Blob and Queue services, and the 2014-02-14 version and later of the File services. Bouw CanonicalizedResource de tekenreeks in deze indeling als volgt:Construct the CanonicalizedResource string in this format as follows:

  1. Begin met een lege tekenreeks (""), een voorwaartse slash (/), gevolgd door de naam van het account dat eigenaar is van de bron die wordt geopend.Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

  2. Het gecodeerde URI-pad van de bron toevoegen, zonder queryparameters.Append the resource's encoded URI path, without any query parameters.

  3. Haal alle queryparameters op de comp resource URI op, inclusief de parameter als deze bestaat.Retrieve all query parameters on the resource URI, including the comp parameter if it exists.

  4. Converteer alle parameternamen naar kleine letters.Convert all parameter names to lowercase.

  5. Sorteer de queryparameters lexicografisch op parameternaam, in oplopende volgorde.Sort the query parameters lexicographically by parameter name, in ascending order.

  6. URL-decoderen elke queryparameternaam en -waarde.URL-decode each query parameter name and value.

  7. Voeg een nieuwregelteken (\n) toe voor elk naam-waardepaar.Include a new-line character (\n) before each name-value pair.

  8. Voeg elke naam en waarde van de queryparameter toe aan de tekenreeks in de volgende indeling en voeg de dubbele punt (:) tussen de naam en de waarde:Append each query parameter name and value to the string in the following format, making sure to include the colon (:) between the name and the value:

    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:If a query parameter has more than one value, sort all values lexicographically, then include them in a comma-separated list:

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

Houd rekening met de volgende regels voor het maken van de canonicalized resource string:Keep in mind the following rules for constructing the canonicalized resource string:

  • Vermijd het gebruik van het nieuwe regelteken (\n) in waarden voor queryparameters.Avoid using the new-line character (\n) in values for query parameters. Als het moet worden gebruikt, moet u ervoor zorgen dat het geen invloed heeft op de indeling van de canonicalized resource string.If it must be used, ensure that it does not affect the format of the canonicalized resource string.

  • Vermijd het gebruik van komma's in queryparameterwaarden.Avoid using commas in query parameter values.

Hier volgen enkele voorbeelden CanonicalizedResource die het gedeelte van de handtekeningtekenreeks weergeven, omdat deze kan worden opgebouwd uit een bepaald verzoek URI:Here are some examples that show the CanonicalizedResource portion of the signature string, as it may be constructed from a given request 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

Gedeelde Key Lite- en Table-serviceindeling voor 2009-09-19 en laterShared Key Lite and Table service format for 2009-09-19 and later

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.This format supports Shared Key and Shared Key Lite for all versions of the Table service, and Shared Key Lite for version 2009-09-19 and later of the Blob and Queue services and version 2014-02-14 and later of the File service. Deze indeling is identiek aan die van eerdere versies van de opslagservices.This format is identical to that used with previous versions of the storage services. Bouw CanonicalizedResource de tekenreeks in deze indeling als volgt:Construct the CanonicalizedResource string in this format as follows:

  1. Begin met een lege tekenreeks (""), een voorwaartse slash (/), gevolgd door de naam van het account dat eigenaar is van de bron die wordt geopend.Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

  2. Het gecodeerde URI-pad van de bron toevoegen.Append the resource's encoded URI path. Als de aanvraag URI een onderdeel van de resource verhelpt, wordt de juiste querytekenreeks toegevoegd.If the request URI addresses a component of the resource, append the appropriate query string. De querytekenreeks moet het vraagteken comp en de ?comp=metadataparameter bevatten (bijvoorbeeld ).The query string should include the question mark and the comp parameter (for example, ?comp=metadata). Er mogen geen andere parameters in de querytekenreeks worden opgenomen.No other parameters should be included on the query string.

De handtekening coderenEncoding the signature

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.To encode the signature, call the HMAC-SHA256 algorithm on the UTF-8-encoded signature string and encode the result as Base64. Houd er rekening mee dat u ook uw opslagaccountsleutel moet decoderen.Note that you also need to Base64-decode your storage account key. Gebruik de volgende indeling (weergegeven als pseudocode):Use the following format (shown as pseudocode):

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

Zie ookSee also