Share via

Autorisieren mit einem gemeinsam verwendeten Schlüssel

  • Artikel

Jede Anforderung für einen Speicherdienst muss autorisiert werden, es sei denn, die Anforderung unterliegt einer Blob- oder Containerressource, die für öffentlichen oder signierten Zugriff zur Verfügung gestellt wurde. Eine Option zum Autorisieren einer Anforderung ist die Verwendung eines gemeinsam genutzten Schlüssels, die in diesem Artikel beschrieben wird.

Wichtig

Für eine optimale Sicherheit empfiehlt Microsoft die Verwendung von Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen für Blob-, Warteschlangen- und Tabellendaten zu autorisieren, wann immer möglich. Die Autorisierung mit Microsoft Entra ID und verwalteten Identitäten bietet eine höhere Sicherheit und Benutzerfreundlichkeit als die Autorisierung mit gemeinsam genutzten Schlüsseln. Weitere Informationen finden Sie unter Autorisieren mit Microsoft Entra ID. Weitere Informationen zu verwalteten Identitäten finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen?

Für Ressourcen, die außerhalb von Azure gehostet werden, z. B. lokale Anwendungen, können Sie verwaltete Identitäten über Azure Arc verwenden. Beispielsweise können Apps, die auf Servern mit Azure Arc-Unterstützung ausgeführt werden, verwaltete Identitäten verwenden, um eine Verbindung mit Azure-Diensten herzustellen. Weitere Informationen finden Sie unter Authentifizieren bei Azure-Ressourcen mit Azure Arc-fähigen Servern.

Für Szenarien, in denen Sass (Shared Access Signatures) verwendet werden, empfiehlt Microsoft die Verwendung einer SAS für die Benutzerdelegierung. Eine SAS für die Benutzerdelegierung wird mit Microsoft Entra Anmeldeinformationen anstelle des Kontoschlüssels geschützt. Weitere Informationen zu Shared Access Signatures finden Sie unter Create einer SAS für die Benutzerdelegierung.

Die Dienste Blob, Warteschlange, Tabelle und Datei 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 mit gemeinsam genutzten Schlüsseln, um Anforderungen an die Blob-, Warteschlangen- und Dateidienste zu senden. Die Autorisierung mit gemeinsam verwendetem Schlüssel in Version 2009-09-19 und höher unterstützt eine Zeichenfolge für erweiterte Signaturen, um die Sicherheit zu verbessern, und erfordert, dass Sie Ihren Dienst aktualisieren, um die Autorisierung mithilfe dieser erweiterten Signatur zu autorisieren.

  • 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 senden. Die Autorisierung mit gemeinsam verwendetem 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 Autorisierungsschema für gemeinsam genutzte Schlüssel, um Anforderungen für die Dienste Blob, Warteschlange, Tabelle und Datei zu senden.

    Für Version 2009-09-19 und höher des Blob- und Warteschlangendiensts unterstützt die Autorisierung mit freigegebenem Schlüssel Lite die Verwendung einer Signaturzeichenfolge, die mit der in früheren Versionen des Blob- und Warteschlangendiensts für gemeinsam genutzten 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.

Eine autorisierte Anforderung erfordert zwei Header: den Date - oder x-ms-date - und den 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 für einen Container festgelegt werden. Weitere Informationen finden Sie unter Verwalten des Zugriffs auf Azure Storage-Ressourcen. Ein Container, Ein Blob, eine Warteschlange oder eine Tabelle kann über eine Shared Access Signature für den signierten Zugriff verfügbar gemacht 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 nicht die Möglichkeit geben, seinen Wert zu lesen, um ihn in die autorisierte Anforderung einzuschließen. 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, ein Blob, eine Warteschlange oder eine 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 Autorisierung mit gemeinsam verwendetem Schlüssel 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 Zeilenumbruchzeichen 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 null ist. In Version 2014-02-14 und früher war die Inhaltslänge auch bei 0 (null) enthalten. 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 Zeilenumbruchzeichen 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 gemeinsam genutzten Schlüsseln 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 zu 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 gemeinsam genutzte Schlüssel lite anstelle von Gemeinsam genutzter Schlüssel verwendet werden. 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.

Content-Length-Header in Version 2014-02-14 und früher

Wenn Version 2014-02-14 oder früher verwendet wird, wenn Content-Length null ist, legen Sie den Content-Length Teil von StringToSign auf fest 0. Normalerweise wäre dies eine leere Zeichenfolge.

Für die folgende Anforderung ist beispielsweise der Wert des Content-Length Headers in StringToSign enthalten, auch wenn er 0 (null) 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 wird wie folgt erstellt:

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 eine StringToSign leere Zeichenfolge für Content-Lengthenthalten sein:

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 mit gemeinsam genutztem Schlüssel)

Sie müssen die Autorisierung mit gemeinsam genutztem Schlüssel verwenden, um eine Anforderung zu autorisieren, die für den Tabellendienst gesendet wird, 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 Shared Key Signature-Zeichenfolge 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 mit der Signaturzeichenfolge identisch, die für die Autorisierung mit freigegebenem Schlüssel in Versionen der Blob- und Warteschlangendienste vor 2009-09-19 erforderlich war. 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. Durch die Verwendung von Shared Key Lite erhalten Sie nicht die erweiterte Sicherheitsfunktionalität, die mithilfe von Shared Key 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 Shared Key Lite-Autorisierung 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 kanonischen 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 lexikographische 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.

Linearer Leerraum umfasst Wagenrücklauf/Zeilenvorschub (CRLF), Leerzeichen und Registerkarten. Weitere Informationen finden Sie unter RFC 2616, Abschnitt 4.2 . Ersetzen Sie keine Leerzeichen in einer Anführungszeichenzeichenfolge.

  1. Kürzen Sie alle Leerzeichen um den Doppelpunkt im Header.

  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 sie direkt dem Doppelpunktzeichen mit der endenden neuen Zeile folgen.

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 Freigabeschlüsselautorisierung 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 die Autorisierung für Azure-Speicherdienste ausführen, wird der Kontoname nur einmal in der CanonicalizedResource Zeichenfolge angezeigt.

Shared Key-Format für 2009-09-19 und höher

Dieses Format unterstützt die Freigabeschlüsselautorisierung 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 neuzeiliges Zeichen (\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 er 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 19.09.2009 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