Autorisieren mit einem gemeinsam verwendeten SchlüsselAuthorize with Shared Key

Jede Anforderung für einen Speicherdienst muss autorisiert werden, es sei denn, die Anforderung betrifft ein Blob oder eine Containerressource, die für den öffentlichen oder signierten Zugriff verfügbar gemacht wurde.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. Eine Option zum Autorisieren einer Anforderung ist die Verwendung des freigegebenen Schlüssels, der in diesem Artikel beschrieben wird.One option for authorizing a request is by using Shared Key, described in this article.

Tipp

Azure Storage unterstützt die Integration mit Azure Active Directory für eine detaillierte Kontrolle über den Zugriff auf Speicherressourcen.Azure Storage supports integration with Azure Active Directory for fine-grained control over access to storage resources. Die Azure AD-Integration wird für die Blob- und Warteschlangendienste unterstützt.Azure AD integration is supported for the Blob and Queue services. Da Azure AD Identitätsverwaltung bereitstellt, können Sie den Zugriff auf Speicherressourcen autorisieren, ohne Ihre Kontozugriffsschlüssel in Ihren Anwendungen zu speichern, wie Sie es mit dem freigegebenen Schlüssel tun.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. Weitere Informationen finden Sie unter Autorisieren mit Azure Active Directory.For more information, see Authorize with Azure Active Directory.

Die Blob-, Warteschlangen-, Tabellen- und Dateidienste unterstützen die folgenden Autorisierungsschemata für gemeinsam genutzte Schlüssel für Version 2009-09-19 und höher (für Blob-, Warteschlangen- und Tabellendienst) und Version 2014-02-14 und höher (für den Dateidienst):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):

  • Gemeinsam verwendeter Schlüssel für BLOB-, Warteschlangen- und Dateidienste.Shared Key for Blob, Queue, and File Services. Verwenden Sie das Autorisierungsschema für freigegebene Schlüssel, um Anforderungen für die Blob-, Warteschlangen- und Dateidienste zu stellen.Use the Shared Key authorization scheme to make requests against the Blob, Queue, and File services. Die Autorisierung des freigegebenen Schlüssels in Version 2009-09-19 und höher unterstützt eine erweiterte Signaturzeichenfolge für erhöhte Sicherheit und erfordert, dass Sie Ihren Dienst aktualisieren, um die Autorisierung mithilfe dieser erweiterten Signatur zu verwenden.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.

  • Gemeinsam verwendeter Schlüssel für den Tabellendienst.Shared Key for Table Service. Verwenden Sie das Autorisierungsschema für freigegebene Schlüssel, um Anforderungen für den Tabellendienst mithilfe der REST-API zu stellen.Use the Shared Key authorization scheme to make requests against the Table service using the REST API. Die Autorisierung des freigegebenen Schlüssels für den Tabellendienst in Version 2009-09-19 und höher verwendet dieselbe Signaturzeichenfolge wie in früheren Versionen des Tabellendienstes.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.

  • Shared Key Lite.Shared Key Lite. Verwenden Sie das Berechtigungsschema "Shared Key Lite", um Anforderungen für die Blob-, Warteschlangen-, Tabellen- und Dateidienste zu stellen.Use the Shared Key Lite authorization scheme to make requests against the Blob, Queue, Table, and File services.

    Für Version 2009-09-19 und höher der Blob- und Warteschlangendienste unterstützt die Autorisierung shared Key Lite die Verwendung einer Signaturzeichenfolge, die mit dem identisch ist, was in früheren Versionen der Blob- und Queue-Dienste für freigegebene Schlüssel unterstützt wurde.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. Daher können Sie Shared Key Lite verwenden, um Anforderungen für die BLOB- und Warteschlangendienste auszuführen, ohne die Signaturzeichenfolge zu aktualisieren.You can therefore use Shared Key Lite to make requests against the Blob and Queue services without updating your signature string.

Für eine autorisierte Anforderung sind Date x-ms-date zwei Header Authorization erforderlich: der oder-Header und der Header.An authorized request requires two headers: the Date or x-ms-date header and the Authorization header. In den folgenden Abschnitten wird beschrieben, wie diese Header erstellt werden.The following sections describe how to construct these headers.

Wichtig

Azure Storage unterstützt sowohl HTTP als auch HTTPS, aber die Verwendung von HTTPS wird dringend empfohlen.Azure Storage support both HTTP and HTTPS, but using HTTPS is highly recommended.

Hinweis

Container oder BLOB-Ressourcen können öffentlich verfügbar gemacht werden, indem die Berechtigungen des Containers festgelegt werden.A container or blob may be made available for public access by setting a container's permissions. Weitere Informationen finden Sie unter Verwalten des Zugriffs auf Azure Storage Resources.For more information, see Manage Access to Azure Storage Resources. Ein Container, Einblob, eine Warteschlange oder eine Tabelle ist möglicherweise für den signierten Zugriff über eine Shared Access-Signatur verfügbar. eine Shared Access-Signatur wird über einen anderen Mechanismus autorisiert.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. Weitere Informationen finden Sie unter Delegatenzugriff mit einer Shared Access-Signatur.See Delegate access with a shared access signature for more details.

Angeben des DatumskopfesSpecifying the Date header

Alle autorisierten Anforderungen müssen den UTC-Zeitstempel (Coordinated Universal Time) für die Anforderung enthalten.All authorized requests must include the Coordinated Universal Time (UTC) timestamp for the request. Sie können den Zeitstempel entweder im x-ms-date-Header oder im standardmäßigen Date-HTTP/HTTPS-Header angeben.You can specify the timestamp either in the x-ms-date header, or in the standard HTTP/HTTPS Date header. Wenn für die Anforderung beide Header angegeben werden, wird der Wert von x-ms-date als Zeitpunkt der Erstellung der Anforderung verwendet.If both headers are specified on the request, the value of x-ms-date is used as the request's time of creation.

Die Speicherdienste stellen sicher, dass eine Anforderung nicht älter als 15 Minuten ist, bis sie den Dienst erreicht.The storage services ensure that a request is no older than 15 minutes by the time it reaches the service. Dies bietet Schutz vor bestimmten Sicherheitsangriffen, einschließlich von Wiedergabenangriffen.This guards against certain security attacks, including replay attacks. Wenn diese Überprüfung fehlschlägt, gibt der Server den Antwortcode 403 (Verboten) zurück.When this check fails, the server returns response code 403 (Forbidden).

Hinweis

Der x-ms-date Header wird bereitgestellt, da einige HTTP-Clientbibliotheken und Proxys den Date Header automatisch festlegen und dem Entwickler keine Möglichkeit geben, seinen Wert zu lesen, um ihn in die autorisierte Anforderung aufzunehmen.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. Wenn Sie x-ms-date festlegen, erstellen Sie die Signatur mit einem leeren Wert für den Date-Header.If you set x-ms-date, construct the signature with an empty value for the Date header.

Angeben des AutorisierungsheadersSpecifying the Authorization header

Eine autorisierte Anforderung Authorization muss den Header enthalten.An authorized request must include the Authorization header. Wenn der Header nicht enthalten ist, ist die Anforderung anonym und wird möglicherweise nur für einen BLOB-Container erfolgreich ausgeführt, der für den öffentlichen Zugriff gekennzeichnet ist, oder für Container, Blobs, Warteschlangen oder Tabellen, für die eine SAS für delegierten Zugriff bereitgestellt wurde.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.

Um eine Anforderung zu autorisieren, müssen Sie die Anforderung mit dem Schlüssel für das Konto signieren, das die Anforderung stellt, und diese Signatur als Teil der Anforderung übergeben.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.

Der Authorization-Header weist das folgende Format auf:The format for the Authorization header is as follows:

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

wobei SharedKey oder SharedKeyLite der Name des Autorisierungsschemas ist. AccountName ist der Name des Kontos, das die Ressource anfordert, und Signature ist ein hashbasierter Nachrichtenauthentifizierungscode (HMAC), der aus der Anforderung erstellt, mit dem SHA256-Algorithmus berechnet und anschließend mit der Base64-Codierung codiert wird.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.

Hinweis

Es ist möglich, eine Ressource anzufordern, die sich unter einem anderen Konto befindet, sofern diese Ressource öffentlich zugänglich ist.It is possible to request a resource that resides beneath a different account, if that resource is publicly accessible.

In den folgenden Abschnitten wird beschrieben, wie der Authorization-Header erstellt wird.The following sections describe how to construct the Authorization header.

Erstellen der SignaturzeichenfolgeConstructing the signature string

Wie Sie die Signaturzeichenfolge erstellen, hängt davon ab, für welchen Dienst und welche Version Sie autorisieren und welches Autorisierungsschema Sie verwenden.How you construct the signature string depends on which service and version you are authorizing against and which authorization scheme you are using. Beachten Sie beim Erstellen der Signaturzeichenfolge Folgendes:When constructing the signature string, keep in mind the following:

  • Der VERB-Teil der Zeichenfolge ist das HTTP-Verb, z. B. GET oder PUT. Dieses muss in Großbuchstaben geschrieben werden.The VERB portion of the string is the HTTP verb, such as GET or PUT, and must be uppercase.

  • Bei der Autorisierung des freigegebenen Schlüssels für die Blob-, Warteschlangen- und Dateidienste kann jeder Header, der in der Signaturzeichenfolge enthalten ist, nur einmal angezeigt werden.For Shared Key authorization for the Blob, Queue, and File services, each header included in the signature string may appear only once. Wenn ein Header dupliziert wird, gibt der Dienst den Statuscode 400 (Ungültige Anforderung) zurück.If any header is duplicated, the service returns status code 400 (Bad Request).

  • Die Werte aller HTTP-Standardheader müssen in der Zeichenfolge ohne die Headernamen in der Reihenfolge enthalten sein, die im Signaturformat aufgeführt wird.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. Diese Header sind möglicherweise leer, wenn sie nicht als Teil der Anforderung angegeben werden. In diesem Fall ist nur das Neue-Zeile-Zeichen erforderlich.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.

  • Wenn der x-ms-date-Header angegeben ist, können Sie den Date-Header ignorieren, unabhängig davon, ob dieser für die Anforderung angegeben ist, und einfach eine Leerzeile für den Date-Teil der Signaturzeichenfolge angeben.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. Befolgen Sie in diesem Fall die Anweisungen im Abschnitt Erstellen der kanonischen Headerzeichenfolge zum Hinzufügen des x-ms-date Headers.In this case, follow the instructions in the Constructing the canonicalized headers string section for adding the x-ms-date header.

    Es ist akzeptabel, x-ms-date Datesowohl als auch anzugeben; In diesem Fall verwendet der x-ms-dateDienst den Wert von .It is acceptable to specify both x-ms-date and Date; in this case, the service uses the value of x-ms-date.

  • Wenn der x-ms-date-Header nicht angegeben ist, geben Sie den Date-Header in der Signaturzeichenfolge ohne den Headernamen an.If the x-ms-date header is not specified, specify the Date header in the signature string, without including the header name.

  • Alle angezeigten Neue-Zeile-Zeichen (\n) sind innerhalb der Signaturzeichenfolge erforderlich.All new-line characters (\n) shown are required within the signature string.

  • Die Signaturzeichenfolge enthält kanonisierte Header und kanonisierte Ressourcenzeichenfolgen.The signature string includes canonicalized headers and canonicalized resource strings. Durch die Kanonisierung werden diese Zeichenfolgen in ein Standardformat umgewandelt, dass von Azure Storage erkannt wird.Canonicalizing these strings puts them into a standard format that is recognized by Azure Storage. Weitere Informationen zum Erstellen der CanonicalizedHeaders-Zeichenfolge und der CanonicalizedResource-Zeichenfolge, die Teil der Signaturzeichenfolge sind, finden Sie in den entsprechenden Abschnitten weiter unten in diesem Thema.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-, Warteschlangen- und Dateidienste (Autorisierung für gemeinsam genutzten Schlüssel)Blob, Queue, and File Services (Shared Key authorization)

Um die Signaturzeichenfolge für den gemeinsam verwendeten Schlüssel für eine Anforderung an den BLOB- oder Warteschlangendienst der Version 2009-09-19 und neuer und an den Dateidienst der Version 2014-02-14 und neuer zu codieren, verwenden Sie folgendes Format: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;  

Wichtig

In der aktuellen Version muss das Feld Content-Length eine leere Zeichenfolge sein, wenn die Inhaltslänge der Anforderung Null ist.In the current version, the Content-Length field must be an empty string if the content length of the request is zero. In version 2014-02-14 und früher wurde die Inhaltslänge auch bei Null enthalten.In version 2014-02-14 and earlier, the content length was included even if zero. Weitere Informationen zum alten Verhalten finden Sie weiter unten.See below for more information on the old behavior.

Das folgende Beispiel zeigt eine Signaturzeichenfolge für einen Blob-Vorgang abrufen.The following example shows a signature string for a Get Blob operation. Wenn kein Headerwert vorhanden ist, wird nur das Zeichen in der neuen Zeile angegeben.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  

In der detaillierten Anzeige der einzelnen Zeilen wird jeder Teil derselben Zeichenfolge aufgeführt: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*/  

Als Nächstes codieren Sie diese Zeichenfolge mit dem HMAC-SHA256-Algorithmus über der in UTF-8 codierten Signaturzeichenfolge, erstellen den Authorization-Header und fügen den Header der Anforderung hinzu.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. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:The following example shows the Authorization header for the same operation:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Um die Autorisierung für gemeinsam genutzten Schlüssel mit Version 2009-09-19 und höher der Blob- und Warteschlangendienste zu verwenden, müssen Sie ihren Code aktualisieren, um diese erweiterte Signaturzeichenfolge zu verwenden.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.

Wenn Sie Ihren Code mit den wenigsten möglichen Änderungen auf Version 2009-09-19 oder höher migrieren Authorization möchten, können Sie Ihre vorhandenen Header so ändern, dass sie Shared Key Lite anstelle des freigegebenen Schlüssels verwenden.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. Das für Shared Key Lite erforderliche Signaturformat ist mit dem identisch, das für gemeinsam verwendete Schlüssel in früheren Versionen als 2009-09-19 der BLOB- und Warteschlangendienste benötigt wird.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.

Wichtig

Wenn Sie auf den sekundären Speicherort in einem Speicherkonto zugreifen, für das Georeplikation mit Lesezugriff (RA-GRS) aktiviert ist, nehmen Sie nicht die -secondary-Bezeichnung in den Authorization-Header auf.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. Zum Zwecke der Autorisierung ist der Kontoname immer der Namen des primären Speicherorts, auch bei sekundärem Zugriff.For authorization purposes, the account name is always the name of the primary location, even for secondary access.

Content-Length Header in Version 2014-02-14 und früherContent-Length header in version 2014-02-14 and earlier

Wenn Sie Version 2014-02-14 Content-Length oder früher verwenden, Content-Length wenn StringToSign Null 0ist, legen Sie den Teil des auf fest.When using version 2014-02-14 or earlier, if Content-Length is zero, then set the Content-Length part of the StringToSign to 0. Normalerweise handelt es sich dabei um eine leere Zeichenfolge.Normally this would be an empty string.

Für die folgende Anforderung wird z. Content-Length B. der StringToSign Wert des Headers in der Datei enthalten, auch wenn er Null ist.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

Der StringToSign ist wie folgt aufgebaut: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

Während in Versionen nach 2014-02-14, die StringToSign muss Content-Lengtheine leere Zeichenfolge für enthalten: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

Tabellendienst (Autorisierung des gemeinsam genutzten Schlüssels)Table service (Shared Key authorization)

Sie müssen die Autorisierung für freigegebenen Schlüssel verwenden, um eine Anforderung für den Tabellendienst zu autorisieren, wenn Ihr Dienst die REST-API verwendet, um die Anforderung zu stellen.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. Das Format der Signaturzeichenfolge für gemeinsam verwendete Schlüssel für den Tabellendienst ist für alle Versionen identisch.The format of the signature string for Shared Key against the Table service is the same for all versions.

Die Signaturzeichenfolge für freigegebene Schlüssel für eine Anforderung für den Tabellendienst unterscheidet sich geringfügig von der CanonicalizedHeaders für eine Anforderung für den Blob- oder Warteschlangendienst, da sie den Teil der Zeichenfolge nicht enthält.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. Außerdem ist der Date-Header in diesem Fall niemals leer, auch dann nicht, wenn die Anforderung den x-ms-date-Header festlegt.Additionally, the Date header in this case is never empty even if the request sets the x-ms-date header. Wenn die Anforderung x-ms-date festlegt, wird dieser Wert auch für den Wert des Date-Headers verwendet.If the request sets x-ms-date, that value is also used for the value of the Date header.

Um die Signaturzeichenfolge für eine mithilfe der REST-API ausgeführten Anforderung für den Tabellendienst zu codieren, verwenden Sie folgendes Format: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;  

Hinweis

Ab Version 2009-09-19 müssen alle REST-Aufrufe für den Tabellendienst den DataServiceVersion-Header und den MaxDataServiceVersion-Header enthalten.Beginning with version 2009-09-19, the Table service requires that all REST calls include the DataServiceVersion and MaxDataServiceVersion headers. Weitere Informationen finden Sie unter Festlegen der OData Data Service Version Header.See Setting the OData Data Service Version Headers for more information.

Blob-, Warteschlangen- und Dateidienste (Shared Key Lite-Autorisierung)Blob, Queue, and File services (Shared Key Lite authorization)

Sie können die Berechtigung Shared Key Lite verwenden, um eine Anforderung zu autorisieren, die für die Version 2009-09-19 und höher für die Blob- und Warteschlangendienste sowie für Version 2014-02-14 und höher der Dateidienste gestellt wurde.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.

Die Signaturzeichenfolge für Shared Key Lite ist identisch mit der Signaturzeichenfolge, die für die Autorisierung freigegebener Schlüssel in Versionen der Blob- und Warteschlangendienste vor dem 19. 2009-09 erforderlich ist.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. Wenn Sie also Ihren Code mit der geringsten Anzahl von Änderungen an Version 2009-09-19 der Blob- und Warteschlangendienste migrieren möchten, können Sie Ihren Code so ändern, dass er Shared Key Lite verwendet, ohne die Signaturzeichenfolge selbst zu ändern.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. Wenn Sie Shared Key Lite verwenden, erhalten Sie nicht die erweiterte Sicherheitsfunktionalität, die durch die Verwendung von Shared Key mit Version 2009-09-19 und höher bereitgestellt wird.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.

Um die Signaturzeichenfolge für eine Anforderung für den BLOB- oder Warteschlangendienst zu codieren, verwenden Sie folgendes Format: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;  

Das folgende Beispiel zeigt eine Signaturzeichenfolge für einen Put Blob-Vorgang.The following example shows a signature string for a Put Blob operation. Beachten Sie, dass die Headerzeile Content-MD5 leer ist.Note that the Content-MD5 header line is empty. Die in der Zeichenfolge gezeigten Header sind Name-Wert-Paare, die benutzerdefinierte Metadatenwerte für das neue BLOB angeben.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  

Als Nächstes codieren Sie diese Zeichenfolge mit dem HMAC-SHA256-Algorithmus über der in UTF-8 codierten Signaturzeichenfolge, erstellen den Authorization-Header und fügen den Header der Anforderung hinzu.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. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:The following example shows the Authorization header for the same operation:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Tabellendienst (Shared Key Lite-Autorisierung)Table service (Shared Key Lite authorization)

Sie können die Berechtigung "Shared Key Lite" verwenden, um eine Anforderung für jede Version des Tabellendienstes zu autorisieren.You can use Shared Key Lite authorization to authorize a request made against any version of the Table service.

Um die Signaturzeichenfolge für eine Anforderung für den Tabellendienst mit Shared Key Lite zu codieren, verwenden Sie folgendes Format:To encode the signature string for a request against the Table service using Shared Key Lite, use the following format:

StringToSign = Date + "\n"
               CanonicalizedResource  

Das folgende Beispiel zeigt eine Signaturzeichenfolge für einen Vorgang Tabelle erstellen.The following example shows a signature string for a Create Table operation.

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

Als Nächstes codieren Sie diese Zeichenfolge mit dem HMAC-SHA256-Algorithmus, erstellen den Authorization-Header und fügen dann der Anforderung den Header hinzu.Next, encode this string by using the HMAC-SHA256 algorithm, construct the Authorization header, and then add the header to the request. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:The following example shows the Authorization header for the same operation:

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

Erstellen der kanonisch-header-ZeichenfolgeConstructing the canonicalized headers string

Führen Sie zum Erstellen des CanonicalizedHeaders-Teils der Signaturzeichenfolge folgende Schritte aus:To construct the CanonicalizedHeaders portion of the signature string, follow these steps:

  1. Rufen Sie alle Header der Ressource ab, die mit x-ms- beginnen, einschließlich des x-ms-date-Headers.Retrieve all headers for the resource that begin with x-ms-, including the x-ms-date header.

  2. Konvertieren Sie alle HTTP-Headernamen in Kleinbuchstaben.Convert each HTTP header name to lowercase.

  3. Sortieren Sie die Header lexikografisch und in aufsteigender Reihenfolge nach Headernamen.Sort the headers lexicographically by header name, in ascending order. Jeder Header darf nur ein Mal in der Zeichenfolge vorhanden sein.Each header may appear only once in the string.

    Hinweis

    Lexikographische Reihenfolge kann nicht immer mit der herkömmlichen alphabetischen Reihenfolge übereinstimmen.Lexicographical ordering may not always coincide with conventional alphabetical ordering.

  4. Ersetzen Sie alle linearen Leerzeichen im Headerwert durch ein einzelnes Leerzeichen.Replace any linear whitespace in the header value with a single space.

Linearer Leerraum umfasst Wagenrücklauf-/Linienvorschub (CRLF), Leerzeichen und Tabs.Linear whitespace includes carriage return/line feed (CRLF), spaces, and tabs. Weitere Informationen finden Sie unter RFC 2616, Abschnitt 4.2.See RFC 2616, section 4.2 for details. Ersetzen Sie keine Leerzeichen innerhalb einer in Anführungszeichen gesetzten Zeichenfolge.Do not replace any whitespace inside a quoted string.

  1. Trimmen Sie alle Leerzeichen um den Doppelpunkt in der Kopfzeile.Trim any whitespace around the colon in the header.

  2. Fügen Sie schließlich jedem kanonisierten Header in der resultierenden Liste ein Neue-Zeile-Zeichen an.Finally, append a new-line character to each canonicalized header in the resulting list. Erstellen Sie die CanonicalizedHeaders-Zeichenfolge, indem Sie alle Header in dieser Liste zu einer einzelnen Zeichenfolge verketten.Construct the CanonicalizedHeaders string by concatenating all headers in this list into a single string.

Das folgende Beispiel zeigt eine Zeichenfolge für einen kanonisierten Header: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

Hinweis

Vor der Dienstversion 2016-05-31 wurden Header mit leeren Werten in der Signaturzeichenfolge weggelassen.Prior to service version 2016-05-31, headers with empty values were omitted from the signature string. Diese werden nun in CanonicalizedHeaders dargestellt, indem sie unmittelbar dem Doppelpunktzeichen mit der beendenden neuen Zeile folgen.These are now represented in CanonicalizedHeaders by immediately following the colon character with the terminating new-line.

Erstellen der kanonischen RessourcenzeichenfolgeConstructing the canonicalized resource string

Der CanonicalizedResource-Teil der Signaturzeichenfolge stellt die Speicherdienstressource dar, die das Ziel der Anforderung ist.The CanonicalizedResource part of the signature string represents the storage services resource targeted by the request. Jeder Teil der CanonicalizedResource-Zeichenfolge, der aus dem URI der Ressource abgeleitet wird, sollte identisch mit dem URI codiert werden.Any portion of the CanonicalizedResource string that is derived from the resource's URI should be encoded exactly as it is in the URI.

Für die CanonicalizedResource-Zeichenfolge werden zwei Formate unterstützt:There are two supported formats for the CanonicalizedResource string:

  • Ein Format, das die Autorisierung des freigegebenen Schlüssels für Version 2009-09-19 und höher der Blob- und Warteschlangendienste sowie für Version 2014-02-14 und höher des Dateidienstes unterstützt.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.

  • Ein Format, das gemeinsam verwendete Schlüssel und Shared Key Lite für alle Versionen des Tabellendiensts unterstützt sowie Shared Key Lite für die Version 2009-09-19 und neuer der BLOB- und Warteschlangendienste.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. Dieses Format ist mit dem in früheren Versionen der Speicherdienste verwendeten Format identisch.This format is identical to that used with previous versions of the storage services.

Hilfe zum Erstellen des URI für die Ressource, auf die Sie zugreifen, finden Sie in einem der folgenden Themen:For help constructing the URI for the resource you are accessing, see one of the following topics:

Wichtig

Wenn Ihr Speicherkonto mithilfe von Georeplikation mit Lesezugriff (RA-GRS) repliziert wird und Sie auf eine Ressource am sekundären Speicherort zugreifen, nehmen Sie nicht die –secondary-Bezeichnung in die CanonicalizedResource-Zeichenfolge auf.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. Der in der CanonicalizedResource-Zeichenfolge verwendete Ressourcen-URI sollte der URI der Ressource am primären Standort sein.The resource URI used in the CanonicalizedResource string URI should be the URI of the resource at the primary location.

Hinweis

Wenn Sie für den Speicheremulator autorisieren, wird der CanonicalizedResource Kontoname zweimal in der Zeichenfolge angezeigt.If you are authorizing against the storage emulator, the account name will appear twice in the CanonicalizedResource string. Dies entspricht dem erwarteten Verhalten.This is expected. Wenn Sie die Autorisierung für Azure-Speicherdienste erstellen, wird CanonicalizedResource der Kontoname nur einmal in der Zeichenfolge angezeigt.If you are authorizing against Azure storage services, the account name will appear only one time in the CanonicalizedResource string.

Shared Key-Format für den 19.09.2009 und höherShared Key format for 2009-09-19 and later

Dieses Format unterstützt die Autorisierung des freigegebenen Schlüssels für die Version 2009-09-19 und höher für die Blob- und Warteschlangendienste sowie für die Version 2014-02-14 und höher der Dateidienste.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. Erstellen Sie die CanonicalizedResource-Zeichenfolge wie folgt in diesem Format:Construct the CanonicalizedResource string in this format as follows:

  1. Beginnen Sie mit einer leeren Zeichenfolge (""), fügen Sie einen Schrägstrich (/) an, gefolgt vom Namen des Kontos, das die Ressource besitzt, auf die zugegriffen wird.Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

  2. Fügen Sie den codierten URI-Pfad der Ressource ohne Abfrageparameter an.Append the resource's encoded URI path, without any query parameters.

  3. Rufen Sie alle Abfrageparameter für den Ressourcen-URI ab, ggf. einschließlich des comp-Parameters.Retrieve all query parameters on the resource URI, including the comp parameter if it exists.

  4. Konvertieren Sie alle Parameternamen in Kleinbuchstaben.Convert all parameter names to lowercase.

  5. Sortieren Sie die Abfrageparameter lexikografisch und in aufsteigender Reihenfolge nach Parameternamen.Sort the query parameters lexicographically by parameter name, in ascending order.

  6. Führen Sie für die Namen und Werte der einzelnen Abfrageparameter eine URL-Decodierung durch.URL-decode each query parameter name and value.

  7. Fügen Sie vor jedem Name-Wert-Paar ein Zeilenumleinige zeichen ein.Include a new-line character (\n) before each name-value pair.

  8. Fügen Sie der Zeichenfolge jeden Abfrageparameternamen und -wert im folgenden Format an, und vergewissern Sie sich, den Doppelpunkt (:) zwischen dem Namen und dem Wert einzuschließen: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. Wenn ein Abfrageparameter mehr als einen Wert aufweist, sortieren Sie alle Werte lexikografisch, und schließen Sie sie dann in eine durch Trennzeichen getrennte Liste ein: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

Beachten Sie die folgenden Regeln zum Erstellen der kanonisierten Ressourcenzeichenfolge:Keep in mind the following rules for constructing the canonicalized resource string:

  • Verwenden Sie das Neue-Zeile-Zeichen (\n) nach Möglichkeit nicht in den Werten für Abfrageparameter.Avoid using the new-line character (\n) in values for query parameters. Wenn Sie es verwenden müssen, vergewissern Sie sich, dass es sich nicht auf das Format der kanonisierten Ressourcenzeichenfolge auswirkt.If it must be used, ensure that it does not affect the format of the canonicalized resource string.

  • Vermeiden Sie die Verwendung von Kommas in den Abfrageparameterwerten.Avoid using commas in query parameter values.

Im Folgenden finden Sie einige Beispiele, die den CanonicalizedResource-Teil der Signaturzeichenfolge zeigen, wie er über einen angegebenen Anforderungs-URI erstellt werden könnte: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

Shared Key Lite und Table-Dienstformat für den 19.09.2009 und höherShared Key Lite and Table service format for 2009-09-19 and later

Dieses Format unterstützt Shared Key und Shared Key Lite für alle Versionen des Tabellendiensts sowie Shared Key Lite für die Version 2009-09-19 und neuer des BLOB- und Warteschlangendiensts sowie Version 2014-02-14 und neuer des Dateidiensts.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. Dieses Format ist mit dem in früheren Versionen der Speicherdienste verwendeten Format identisch.This format is identical to that used with previous versions of the storage services. Erstellen Sie die CanonicalizedResource-Zeichenfolge wie folgt in diesem Format:Construct the CanonicalizedResource string in this format as follows:

  1. Beginnen Sie mit einer leeren Zeichenfolge (""), fügen Sie einen Schrägstrich (/) an, gefolgt vom Namen des Kontos, das die Ressource besitzt, auf die zugegriffen wird.Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

  2. Fügen Sie den codierten URI-Pfad der Ressource an.Append the resource's encoded URI path. Wenn der Anforderungs-URI eine Komponente der Ressource adressiert, fügen Sie die entsprechende Abfragezeichenfolge an.If the request URI addresses a component of the resource, append the appropriate query string. Die Abfragezeichenfolge sollte das Fragezeichen und den comp-Parameter enthalten (z. B. ?comp=metadata).The query string should include the question mark and the comp parameter (for example, ?comp=metadata). Andere Parameter sollten nicht in der Abfragezeichenfolge enthalten sein.No other parameters should be included on the query string.

Kodien der SignaturEncoding the signature

Um die Signatur zu codieren, rufen Sie den HMAC-SHA256-Algorithmus für die in UTF-8 codierte Signaturzeichenfolge auf, und codieren Sie das Ergebnis als Base64.To encode the signature, call the HMAC-SHA256 algorithm on the UTF-8-encoded signature string and encode the result as Base64. Beachten Sie, dass Sie auch Ihren Speicherkontoschlüssel von Base64 dekodieren müssen.Note that you also need to Base64-decode your storage account key. Verwenden Sie folgendes Format (als Pseudocode angezeigt):Use the following format (shown as pseudocode):

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

Weitere InformationenSee also