Autorisieren mit einem gemeinsam verwendeten Schlüssel

  • Artikel

Jede Anforderung für einen Speicherdienst muss autorisiert werden, es sei denn, die Anforderung richtet sich an eine Blob- oder Containerressource, die für den öffentlichen oder signierten Zugriff zur Verfügung gestellt wurde. Eine Option zum Autorisieren einer Anforderung ist die Verwendung des freigegebenen Schlüssels, die in diesem Artikel beschrieben wird.

Tipp

Azure Storage bietet die Integration mit Microsoft Entra ID für die identitätsbasierte Autorisierung von Anforderungen an die Blob-, Datei-, Warteschlangen- und Tabellendienste. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) verwenden, um Benutzern, Gruppen oder Anwendungen Zugriff auf Blob-, Datei-, Warteschlangen- und Tabellenressourcen zu gewähren. Microsoft Entra ID kann verwendet werden, um den Zugriff auf Speicherressourcen zu autorisieren, ohne Ihre Kontozugriffsschlüssel in Ihren Anwendungen zu speichern, wie Sie dies mit freigegebenem Schlüssel tun. Weitere Informationen finden Sie unter Autorisieren mit Microsoft Entra ID.

Die Blob-, Warteschlangen-, Tabellen- und Dateidienste unterstützen die folgenden Autorisierungsschemas 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 Dateidienst):

  • Gemeinsam verwendeter Schlüssel für BLOB-, Warteschlangen- und Dateidienste. Verwenden Sie das Autorisierungsschema für gemeinsam genutzte Schlüssel, um Anforderungen für die Blob-, Warteschlangen- und Dateidienste zu stellen. 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 so aktualisieren, dass er mithilfe dieser erweiterten Signatur autorisiert wird.

  • Gemeinsam verwendeter Schlüssel für den Tabellendienst. Verwenden Sie das Autorisierungsschema für gemeinsam genutzte Schlüssel, um Anforderungen an den Tabellendienst mithilfe der REST-API zu stellen. Die Autorisierung mit freigegebenem Schlüssel für den Tabellendienst in Version 2009-09-19 und höher verwendet dieselbe Signaturzeichenfolge wie in früheren Versionen des Tabellendiensts.

  • Shared Key Lite. Verwenden Sie das Shared Key Lite-Autorisierungsschema, um Anforderungen für die Blob-, Warteschlangen-, Tabellen- und Dateidienste zu stellen.

    Für Version 2009-09-19 und höher der Blob- und Warteschlangendienste unterstützt die Shared Key Lite-Autorisierung die Verwendung einer Signaturzeichenfolge, die mit der in früheren Versionen des Blob- und Warteschlangendiensts für freigegebenen Schlüssel identisch ist. Daher können Sie Shared Key Lite verwenden, um Anforderungen für die BLOB- und Warteschlangendienste auszuführen, ohne die Signaturzeichenfolge zu aktualisieren.

Für eine autorisierte Anforderung sind zwei Header erforderlich: der Date - oder x-ms-date - und der Authorization Header. In den folgenden Abschnitten wird beschrieben, wie diese Header erstellt werden.

Wichtig

Azure Storage unterstützt sowohl HTTP als auch HTTPS, aber die Verwendung von HTTPS wird dringend empfohlen.

Hinweis

Ein Container oder Blob kann für den öffentlichen Zugriff verfügbar gemacht werden, indem die Berechtigungen eines Containers festgelegt werden. Weitere Informationen finden Sie unter Verwalten des Zugriffs auf Azure Storage-Ressourcen. Ein Container, Blob, Eine Warteschlange oder eine Tabelle kann für den signierten Zugriff über eine freigegebene Zugriffssignatur zur Verfügung gestellt werden. eine Shared Access Signature wird über einen anderen Mechanismus autorisiert. Weitere Informationen finden Sie unter Delegieren des Zugriffs mit einer Shared Access Signature .

Angeben des Date-Headers

Alle autorisierten Anforderungen müssen den UTC-Zeitstempel (Coordinated Universal Time) für die Anforderung enthalten. Sie können den Zeitstempel entweder im x-ms-date-Header oder im standardmäßigen Date-HTTP/HTTPS-Header angeben. Wenn für die Anforderung beide Header angegeben werden, wird der Wert von x-ms-date als Zeitpunkt der Erstellung der Anforderung verwendet.

Die Speicherdienste stellen sicher, dass eine Anforderung nicht älter als 15 Minuten ist, bis sie den Dienst erreicht. Dies bietet Schutz vor bestimmten Sicherheitsangriffen, einschließlich von Wiedergabenangriffen. Wenn diese Überprüfung fehlschlägt, gibt der Server den Antwortcode 403 (Verboten) zurück.

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. Wenn Sie x-ms-date festlegen, erstellen Sie die Signatur mit einem leeren Wert für den Date-Header.

Angeben des Autorisierungsheaders

Eine autorisierte Anforderung muss den Authorization Header enthalten. Wenn dieser Header nicht enthalten ist, ist die Anforderung anonym und nur für einen Container oder Blob erfolgreich, der für den öffentlichen Zugriff markiert ist, oder für einen Container, blob, eine Warteschlange oder Tabelle, für die eine Shared Access Signature für den delegierten Zugriff bereitgestellt wurde.

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.

Der Authorization-Header weist das folgende Format auf:

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.

Hinweis

Es ist möglich, eine Ressource anzufordern, die sich unter einem anderen Konto befindet, sofern diese Ressource öffentlich zugänglich ist.

In den folgenden Abschnitten wird beschrieben, wie der Authorization-Header erstellt wird.

Erstellen der Signaturzeichenfolge

Wie Sie die Signaturzeichenfolge erstellen, hängt davon ab, für welchen Dienst und welche Version Sie autorisieren und welches Autorisierungsschema Sie verwenden. Beachten Sie beim Erstellen der Signaturzeichenfolge Folgendes:

  • Der VERB-Teil der Zeichenfolge ist das HTTP-Verb, z. B. GET oder PUT. Dieses muss in Großbuchstaben geschrieben werden.

  • Bei der Freigabeschlüsselautorisierung für die Blob-, Warteschlangen- und Dateidienste kann jeder in der Signaturzeichenfolge enthaltene Header nur einmal angezeigt werden. Wenn ein Header dupliziert wird, gibt der Dienst den Statuscode 400 (Ungültige Anforderung) zurück.

  • Die Werte aller HTTP-Standardheader müssen in der Zeichenfolge ohne die Headernamen in der Reihenfolge enthalten sein, die im Signaturformat aufgeführt wird. Diese Header können leer sein, wenn sie nicht als Teil der Anforderung angegeben werden. in diesem Fall ist nur das neuzeilige Zeichen erforderlich.

  • Wenn der x-ms-date Header angegeben ist, können Sie den Date Header ignorieren, unabhängig davon, ob er in der Anforderung angegeben ist, und einfach eine leere Zeile für den Date Teil der Signaturzeichenfolge angeben. Befolgen Sie in diesem Fall die Anweisungen im Abschnitt Erstellen der kanonisierten Headerzeichenfolge zum Hinzufügen des x-ms-date Headers.

    Es ist akzeptabel, sowohl als Dateauch x-ms-date anzugeben. In diesem Fall verwendet der Dienst den Wert von x-ms-date.

  • Wenn der x-ms-date-Header nicht angegeben ist, geben Sie den Date-Header in der Signaturzeichenfolge ohne den Headernamen an.

  • Alle angezeigten Neue-Zeile-Zeichen (\n) sind innerhalb der Signaturzeichenfolge erforderlich.

  • Die Signaturzeichenfolge enthält kanonisierte Header und kanonisierte Ressourcenzeichenfolgen. Durch die Kanonisierung werden diese Zeichenfolgen in ein Standardformat umgewandelt, dass von Azure Storage erkannt wird. 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.

Blob-, Warteschlangen- und Dateidienste (Shared Key-Autorisierung)

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:

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 Inhaltslänge eine leere Zeichenfolge sein, wenn die Inhaltslänge der Anforderung 0 ist. In Version 2014-02-14 und früher war die Inhaltslänge enthalten, auch wenn es 0 ist. Weitere Informationen zum alten Verhalten finden Sie weiter unten.

Das folgende Beispiel zeigt eine Signaturzeichenfolge für einen Get Blob-Vorgang . Wenn kein Headerwert vorhanden ist, wird nur das neuzeilige Zeichen angegeben.

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:

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. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Um die Autorisierung mit freigegebenem Schlüssel mit Version 2009-09-19 und höher der Blob- und Warteschlangendienste zu verwenden, müssen Sie Ihren Code so aktualisieren, dass diese erweiterte Signaturzeichenfolge verwendet wird.

Wenn Sie Ihren Code lieber auf Version 2009-09-19 oder höher der Blob- und Warteschlangendienste mit den wenigsten möglichen Änderungen migrieren möchten, können Sie Ihre vorhandenen Authorization Header so ändern, dass Shared Key Lite anstelle von Shared Key verwendet wird. 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.

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. Zum Zwecke der Autorisierung ist der Kontoname immer der Namen des primären Speicherorts, auch bei sekundärem Zugriff.

Inhaltslängenheader in Version 2014-02-14 und früher

Legen Sie bei Verwendung von Version 2014-02-14 oder früher, wenn Content-Length null ist, den Content-Length Teil von StringToSign auf fest 0. Normalerweise ist dies eine leere Zeichenfolge.

Für die folgende Anforderung ist beispielsweise der Wert des Content-Length Headers in der StringToSign enthalten, auch wenn er 0 ist.

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

Die StringToSign ist wie folgt aufgebaut:

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

In Versionen nach 2014-02-14 muss die StringToSign eine leere Zeichenfolge für Content-Lengthenthalten:

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 (Shared Key-Autorisierung)

Sie müssen die Autorisierung mit freigegebenem Schlüssel verwenden, um eine Anforderung für den Tabellendienst zu autorisieren, wenn Ihr Dienst die REST-API verwendet, um die Anforderung zu stellen. Das Format der Signaturzeichenfolge für gemeinsam verwendete Schlüssel für den Tabellendienst ist für alle Versionen identisch.

Die Signaturzeichenfolge für gemeinsam genutzte Schlüssel für eine Anforderung für den Tabellendienst unterscheidet sich geringfügig von der für eine Anforderung für den Blob- oder Warteschlangendienst, da sie den CanonicalizedHeaders Teil der Zeichenfolge nicht enthält. Außerdem ist der Date-Header in diesem Fall niemals leer, auch dann nicht, wenn die Anforderung den x-ms-date-Header festlegt. Wenn die Anforderung x-ms-date festlegt, wird dieser Wert auch für den Wert des Date-Headers verwendet.

Um die Signaturzeichenfolge für eine mithilfe der REST-API ausgeführten Anforderung für den Tabellendienst zu codieren, verwenden Sie folgendes 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. Weitere Informationen finden Sie unter Festlegen der OData Data Service-Versionsheader .

Blob-, Warteschlangen- und Dateidienste (Shared Key Lite-Autorisierung)

Sie können die Shared Key Lite-Autorisierung verwenden, um eine Anforderung zu autorisieren, die für die Version 2009-09-19 und höher der Blob- und Warteschlangendienste und die Version 2014-02-14 der Dateidienste gestellt wurde.

Die Signaturzeichenfolge für Shared Key Lite ist identisch mit der Signaturzeichenfolge, die vor dem 19.09.2009 für die Autorisierung mit gemeinsam genutzten Schlüsseln in Den Blob- und Warteschlangendiensten erforderlich war. Wenn Sie Also Ihren Code mit der geringsten Anzahl von Änderungen an Version 2009-09-19 des Blob- und Warteschlangendiensts migrieren möchten, können Sie Ihren Code so ändern, dass shared Key Lite verwendet wird, ohne die Signaturzeichenfolge selbst zu ändern. Durch die Verwendung von Shared Key Lite erhalten Sie nicht die erweiterte Sicherheitsfunktionalität, die durch die Verwendung von gemeinsam genutztem Schlüssel mit Version 2009-09-19 und höher bereitgestellt wird.

Um die Signaturzeichenfolge für eine Anforderung für den BLOB- oder Warteschlangendienst zu codieren, verwenden Sie folgendes 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 . Beachten Sie, dass die Headerzeile Content-MD5 leer ist. Die in der Zeichenfolge gezeigten Header sind Name-Wert-Paare, die benutzerdefinierte Metadatenwerte für das neue BLOB angeben.

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. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Tabellendienst (Shared Key Lite-Autorisierung)

Sie können die Autorisierung mit gemeinsam genutzten Schlüsseln verwenden, um eine Anforderung für eine beliebige Version des Tabellendiensts zu autorisieren.

Um die Signaturzeichenfolge für eine Anforderung für den Tabellendienst mit Shared Key Lite zu codieren, verwenden Sie folgendes Format:

StringToSign = Date + "\n"
               CanonicalizedResource

Das folgende Beispiel zeigt eine Signaturzeichenfolge für einen Create Table-Vorgang .

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. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:

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

Erstellen der kanonisierten Headerzeichenfolge

Führen Sie zum Erstellen des CanonicalizedHeaders-Teils der Signaturzeichenfolge folgende Schritte aus:

  1. Rufen Sie alle Header der Ressource ab, die mit x-ms- beginnen, einschließlich des x-ms-date-Headers.

  2. Konvertieren Sie alle HTTP-Headernamen in Kleinbuchstaben.

  3. Sortieren Sie die Header lexikografisch und in aufsteigender Reihenfolge nach Headernamen. Jeder Header kann nur einmal in der Zeichenfolge angezeigt werden.

    Hinweis

    Die lexikografische Reihenfolge stimmt möglicherweise nicht immer mit der herkömmlichen alphabetischen Reihenfolge überein.

  4. Ersetzen Sie alle linearen Leerzeichen im Headerwert durch ein einzelnes Leerzeichen.

Lineare Leerzeichen umfassen Wagenrücklauf/Zeilenvorschub (CRLF), Leerzeichen und Registerkarten. Weitere Informationen finden Sie unter RFC 2616, Abschnitt 4.2 . Ersetzen Sie keine Leerzeichen innerhalb einer Zeichenfolge in Anführungszeichen.

  1. Kürzen Sie alle Leerzeichen um den Doppelpunkt in der Kopfzeile.

  2. Fügen Sie schließlich jedem kanonisierten Header in der resultierenden Liste ein Neue-Zeile-Zeichen an. Erstellen Sie die CanonicalizedHeaders-Zeichenfolge, indem Sie alle Header in dieser Liste zu einer einzelnen Zeichenfolge verketten.

Das folgende Beispiel zeigt eine Zeichenfolge für einen kanonisierten Header:

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

Hinweis

Vor Dienstversion 2016-05-31 wurden Header mit leeren Werten aus der Signaturzeichenfolge weggelassen. Diese werden jetzt in CanonicalizedHeaders dargestellt, indem direkt auf das Doppelpunktzeichen mit der endenden new-line folgt.

Erstellen der kanonisierten Ressourcenzeichenfolge

Der CanonicalizedResource-Teil der Signaturzeichenfolge stellt die Speicherdienstressource dar, die das Ziel der Anforderung ist. Jeder Teil der CanonicalizedResource-Zeichenfolge, der aus dem URI der Ressource abgeleitet wird, sollte identisch mit dem URI codiert werden.

Für die CanonicalizedResource-Zeichenfolge werden zwei Formate unterstützt:

  • Ein Format, das die Autorisierung mit gemeinsam verwendeten Schlüsseln für Version 2009-09-19 und höher der Blob- und Warteschlangendienste sowie für Version 2014-02-14 und höher des Dateidiensts unterstützt.

  • 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. Dieses Format ist mit dem in früheren Versionen der Speicherdienste verwendeten Format identisch.

Hilfe zum Erstellen des URI für die Ressource, auf die Sie zugreifen, finden Sie in einem der folgenden Themen:

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. Der in der CanonicalizedResource-Zeichenfolge verwendete Ressourcen-URI sollte der URI der Ressource am primären Standort sein.

Hinweis

Wenn Sie die Autorisierung für den Speicheremulator durchführen, wird der Kontoname zweimal in der CanonicalizedResource Zeichenfolge angezeigt. Dies entspricht dem erwarteten Verhalten. Wenn Sie für Azure-Speicherdienste autorisieren, wird der Kontoname nur einmal in der CanonicalizedResource Zeichenfolge angezeigt.

Format für gemeinsam genutzte Schlüssel für 2009-09-19 und höher

Dieses Format unterstützt die Autorisierung mit gemeinsam genutzten Schlüsseln für die Version 2009-09-19 und höher der Blob- und Warteschlangendienste sowie die Version 2014-02-14 und höher der Dateidienste. Erstellen Sie die CanonicalizedResource-Zeichenfolge wie folgt in diesem Format:

  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.

  2. Fügen Sie den codierten URI-Pfad der Ressource ohne Abfrageparameter an.

  3. Rufen Sie alle Abfrageparameter für den Ressourcen-URI ab, ggf. einschließlich des comp-Parameters.

  4. Konvertieren Sie alle Parameternamen in Kleinbuchstaben.

  5. Sortieren Sie die Abfrageparameter lexikografisch und in aufsteigender Reihenfolge nach Parameternamen.

  6. Führen Sie für die Namen und Werte der einzelnen Abfrageparameter eine URL-Decodierung durch.

  7. Fügen Sie vor jedem Name-Wert-Paar ein Zeilenumbruchzeichen (\n) ein.

  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:

    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:

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

Beachten Sie die folgenden Regeln zum Erstellen der kanonisierten Ressourcenzeichenfolge:

  • Verwenden Sie das Neue-Zeile-Zeichen (\n) nach Möglichkeit nicht in den Werten für Abfrageparameter. Wenn Sie es verwenden müssen, vergewissern Sie sich, dass es sich nicht auf das Format der kanonisierten Ressourcenzeichenfolge auswirkt.

  • Vermeiden Sie die Verwendung von Kommas in den Abfrageparameterwerten.

Im Folgenden finden Sie einige Beispiele, die den CanonicalizedResource Teil der Signaturzeichenfolge zeigen, da sie aus einem bestimmten Anforderungs-URI erstellt werden kann:

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 Tabellendienstformat für 2009-09-19 und höher

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. Dieses Format ist mit dem in früheren Versionen der Speicherdienste verwendeten Format identisch. Erstellen Sie die CanonicalizedResource-Zeichenfolge wie folgt in diesem Format:

  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.

  2. Fügen Sie den codierten URI-Pfad der Ressource an. Wenn der Anforderungs-URI eine Komponente der Ressource adressiert, fügen Sie die entsprechende Abfragezeichenfolge an. Die Abfragezeichenfolge sollte das Fragezeichen und den comp-Parameter enthalten (z. B. ?comp=metadata). Andere Parameter sollten nicht in der Abfragezeichenfolge enthalten sein.

Codieren der Signatur

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. Beachten Sie, dass Sie Ihren Speicherkontoschlüssel auch mit Base64 decodieren müssen. Verwenden Sie folgendes Format (als Pseudocode angezeigt):

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

Weitere Informationen