Freigeben über

Autorisieren mit freigegebenem Schlüssel

  • Artikel

Jede Anforderung für einen Speicherdienst muss autorisiert werden, es sei denn, die Anforderung ist für eine Blob- oder Containerressource vorgesehen, die für den öffentlichen oder signierten Zugriff verfügbar gemacht wurde. Eine Option zum Autorisieren einer Anforderung ist die Verwendung des freigegebenen Schlüssels, der in diesem Artikel beschrieben wird.

Wichtig

Für eine optimale Sicherheit empfiehlt Microsoft die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen für Blob-, Warteschlangen- und Tabellendaten zu autorisieren, wenn möglich. Die Autorisierung mit Microsoft Entra ID und verwalteten Identitäten bietet eine überlegene Sicherheit und Benutzerfreundlichkeit gegenüber der Shared Key-Autorisierung. 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 Azure Arc-fähigen Servern ausgeführt werden, verwaltete Identitäten verwenden, um eine Verbindung mit Azure-Diensten herzustellen. Weitere Informationen finden Sie unter Authentifizieren von Azure-Ressourcen mit Azure Arc-fähigen Servern.

Für Szenarien, in denen freigegebene Zugriffssignaturen (SAS) verwendet werden, empfiehlt Microsoft die Verwendung einer Benutzerdelegierungs-SAS. Eine Benutzerdelegierungs-SAS ist anstelle des Kontoschlüssels mit Microsoft Entra-Anmeldeinformationen gesichert. Informationen zu freigegebenen Zugriffssignaturen finden Sie unter Erstellen einer Benutzerdelegierung SAS-.

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, Warteschlange und Tabellendienst) und Version 2014-02-14 und höher (für den Dateidienst):

  • Freigegebener 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 für gemeinsam genutzte Schlüssel 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 Verwendung dieser erweiterten Signatur zu autorisieren.

  • Shared Key for Table Service. Verwenden Sie das Autorisierungsschema für gemeinsam genutzte Schlüssel, um Anforderungen an den Tabellendienst mithilfe der REST-API zu senden. Die Autorisierung für gemeinsame Schlüssel für den Tabellendienst in Version 2009-09-19 und höher verwendet dieselbe Signaturzeichenfolge wie in früheren Versionen des Tabellendiensts.

  • Freigegebener Schlüssel Lite. Verwenden Sie das Autorisierungsschema "Shared Key Lite", um Anforderungen an die Blob-, Warteschlangen-, Tabellen- und Dateidienste zu senden. Shared Key Lite wird für Premium-Seitenblobs nicht unterstützt.

    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 dem identisch ist, was in früheren Versionen der Blob- und Warteschlangendienste gegen shared Key unterstützt wurde. Sie können daher Shared Key Lite verwenden, um Anforderungen für die Blob- und Warteschlangendienste auszuführen, ohne Ihre Signaturzeichenfolge zu aktualisieren.

Eine autorisierte Anforderung erfordert zwei Header: den Date- oder x-ms-date-Header und den Authorization-Header. In den folgenden Abschnitten wird beschrieben, wie sie diese Kopfzeilen erstellen.

Wichtig

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

Anmerkung

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 Resources. Ein Container, Blob, Warteschlangen oder Eine Tabelle kann über eine freigegebene Zugriffssignatur für signierten Zugriff verfügbar gemacht werden; Eine Gemeinsame Zugriffssignatur ist über einen anderen Mechanismus autorisiert. Weitere Informationen finden Sie unter Stellvertretungszugriff mit einer freigegebenen Zugriffssignatur.

Angeben der Datumskopfzeile

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 HTTP/HTTPS-Date-Header angeben. Wenn beide Header für die Anforderung angegeben werden, wird der Wert x-ms-date als Erstellungszeit der Anforderung verwendet.

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

Anmerkung

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 einzuschließen. Wenn Sie x-ms-datefestlegen, erstellen Sie die Signatur mit einem leeren Wert für die kopfzeile Date.

Angeben des Autorisierungsheaders

Eine autorisierte Anforderung muss den Authorization Header enthalten. Wenn dieser Header nicht enthalten ist, ist die Anforderung anonym und kann nur für einen Container oder blob ausgeführt werden, der für den öffentlichen Zugriff gekennzeichnet ist, oder für einen Container, blob, eine Warteschlange oder eine Tabelle, für die eine Signatur für freigegebenen Zugriff für 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 vornimmt, und diese Signatur als Teil der Anforderung übergeben.

Das Format für die Authorization Kopfzeile lautet wie folgt:

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

wobei SharedKey oder SharedKeyLite der Name des Autorisierungsschemas ist, ist AccountName der Name des Kontos, das die Ressource anfordert, und Signature ein hashbasierter Nachrichtenauthentifizierungscode (HMAC) ist, der aus der Anforderung erstellt und mithilfe des SHA256-Algorithmus berechnet und dann mithilfe der Base64-Codierung codiert wird.

Anmerkung

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

In den folgenden Abschnitten wird beschrieben, wie Sie die Authorization Kopfzeile erstellen.

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, und muss groß geschrieben sein.

  • Für die Autorisierung gemeinsam genutzter Schlüssel für die Blob-, Warteschlangen- und Dateidienste kann jeder in der Signaturzeichenfolge enthaltene Header nur einmal angezeigt werden. Wenn ein Header dupliziert ist, gibt der Dienst den Statuscode 400 (Ungültige Anforderung) zurück.

  • Die Werte aller standardmäßigen HTTP-Header müssen in der Zeichenfolge in der Reihenfolge enthalten sein, die im Signaturformat ohne die Headernamen angezeigt wird. Diese Header können leer sein, wenn sie nicht als Teil der Anforderung angegeben werden. in diesem Fall ist nur das neue Zeilenzeichen 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 Erstellen der kanonischen Überschriftenzeichenfolge Abschnitt zum Hinzufügen der x-ms-date Kopfzeile.

    Es ist akzeptabel, sowohl x-ms-date als auch Dateanzugeben; 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 an, ohne den Kopfzeilennamen einzuschliessen.

  • Alle angezeigten Zeilenzeichen (\n) sind innerhalb der Signaturzeichenfolge erforderlich.

  • Die Signaturzeichenfolge enthält kanonische Kopfzeilen und kanonische Ressourcenzeichenfolgen. Die Kanonisierung dieser Zeichenfolgen fügt sie in ein Standardformat ein, das von Azure Storage erkannt wird. Ausführliche Informationen zum Erstellen der CanonicalizedHeaders und CanonicalizedResource Zeichenfolgen, die Teil der Signaturzeichenfolge sind, finden Sie weiter unten in diesem Thema in den entsprechenden Abschnitten.

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

Verwenden Sie das folgende Format, um die Signaturzeichenfolge für gemeinsame Schlüssel für eine Anforderung für die Version 2009-09-19 und höher des Blob- oder Warteschlangendiensts und Version 2014-02-14 und höher des Dateidiensts zu codieren:

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 Version 2014-02-14 und früher wurde die Inhaltslänge auch dann eingeschlossen, wenn null. Weitere Informationen zum alten Verhalten finden Sie unten.

Das folgende Beispiel zeigt eine Signaturzeichenfolge für einen Vorgang "Blob- abrufen". Wenn kein Kopfzeilenwert vorhanden ist, wird nur das neue Zeilenzeichen 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

Durchbrechen dieser Zeile nach Zeile zeigt jeden Teil derselben Zeichenfolge:

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

Codieren Sie als Nächstes diese Zeichenfolge mithilfe des HMAC-SHA256 Algorithmus über die UTF-8-codierte Signaturzeichenfolge, erstellen Sie den Authorization Header, und fügen Sie der Anforderung den Header hinzu. Das folgende Beispiel zeigt den Authorization-Header für denselben Vorgang:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Um die Autorisierung für gemeinsam genutzte 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.

Wenn Sie Ihren Code lieber zu Version 2009-09-19 oder höher der Blob- und Warteschlangendienste mit den wenigen möglichen Änderungen migrieren möchten, können Sie Ihre vorhandenen Authorization Header so ändern, dass "Shared Key Lite" anstelle von "Freigegebener Schlüssel" verwendet wird. Das von Shared Key Lite erforderliche Signaturformat ist identisch mit dem, das für gemeinsame Schlüssel von Versionen der Blob- und Warteschlangendienste vor 2009-09-19 erforderlich ist.

Wichtig

Wenn Sie auf den sekundären Standort in einem Speicherkonto zugreifen, für das die Georeplikation mit Lesezugriff (RA-GRS) aktiviert ist, schließen Sie die -secondary-Bezeichnung nicht in den Autorisierungsheader ein. Für Autorisierungszwecke ist der Kontoname immer der Name des primären Standorts, auch für sekundären Zugriff.

Header "Inhaltslänge" in Version 2014-02-14 und früher

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

Für die folgende Anforderung ist beispielsweise der Wert des Content-Length Headers in der StringToSign enthalten, auch wenn er 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 konstruiert:

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 Authorization)

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

Die Signaturzeichenfolge für gemeinsame 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 nicht den CanonicalizedHeaders Teil der Zeichenfolge enthält. Darüber hinaus ist der Date Header in diesem Fall nie leer, auch wenn die Anforderung den x-ms-date Header festlegt. Wenn die Anforderung x-ms-datefestlegt, wird dieser Wert auch für den Wert des Date Headers verwendet.

Verwenden Sie das folgende Format, um die Signaturzeichenfolge für eine Anforderung für den Tabellendienst zu codieren, der mit der REST-API erstellt wurde:

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

Anmerkung

Ab Version 2009-09-19 erfordert der Tabellendienst, dass alle REST-Aufrufe die DataServiceVersion und 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 für die Version 2009-09-19 und höher der Blob- und Warteschlangendienste und Version 2014-02-14 und höher der Dateidienste zu autorisieren. Shared Key Lite wird für Premium-Seitenblobs nicht unterstützt.

Die Signaturzeichenfolge für Shared Key Lite ist identisch mit der Signaturzeichenfolge, die für die Autorisierung gemeinsam genutzter Schlüssel in Versionen der Blob- und Warteschlangendienste vor 2009-09-19 erforderlich ist. Wenn Sie Ihren Code also 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 shared Key Lite verwendet wird, ohne die Signaturzeichenfolge selbst zu ändern. Mithilfe von Shared Key Lite erhalten Sie nicht die erweiterte Sicherheitsfunktionalität, die mit Shared Key mit Version 2009-09-19 und höher bereitgestellt wird.

Verwenden Sie das folgende Format, um die Signaturzeichenfolge für eine Anforderung für den Blob- oder Warteschlangendienst zu codieren:

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 Content-MD5-Headerzeile leer ist. Die in der Zeichenfolge angezeigten 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

Codieren Sie als Nächstes diese Zeichenfolge mithilfe des HMAC-SHA256 Algorithmus über die UTF-8-codierte Signaturzeichenfolge, erstellen Sie den Authorization Header, und fügen Sie der Anforderung den Header hinzu. Das folgende Beispiel zeigt den Authorization-Header für denselben Vorgang:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Tabellendienst (Shared Key Lite-Autorisierung)

Sie können die Shared Key Lite-Autorisierung verwenden, um eine Anforderung für jede Version des Tabellendiensts zu autorisieren.

Verwenden Sie das folgende Format, um die Signaturzeichenfolge für eine Anforderung für den Tabellendienst mit Shared Key Lite zu codieren:

StringToSign = Date + "\n"
               CanonicalizedResource

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

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

Codieren Sie als Nächstes diese Zeichenfolge mithilfe des HMAC-SHA256-Algorithmus, erstellen Sie den Authorization-Header, und fügen Sie dann der Anforderung den Header hinzu. Das folgende Beispiel zeigt den Authorization-Header für denselben Vorgang:

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

Erstellen der kanonischen Headerzeichenfolge

Führen Sie die folgenden Schritte aus, um den CanonicalizedHeaders Teil der Signaturzeichenfolge zu erstellen:

  1. Rufen Sie alle Kopfzeilen für die Ressource ab, die mit x-ms-beginnen, einschließlich des x-ms-date-Headers.

  2. Konvertieren Sie jeden HTTP-Headernamen in Kleinbuchstaben.

  3. Sortieren Sie die Kopfzeilen lexikalisch nach Kopfzeilennamen in aufsteigender Reihenfolge. Jede Kopfzeile kann nur einmal in der Zeichenfolge angezeigt werden.

    Anmerkung

    Lexikographische Sortierung nicht immer mit herkömmlicher alphabetischer Reihenfolge übereinstimmen.

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

Lineare Leerzeichen umfassen Wagenrücklauf-/Zeilenvorschub (CRLF), Leerzeichen und Tabstopps. Ausführliche Informationen finden Sie unter RFC 2616, Abschnitt 4.2. Ersetzen Sie keine Leerzeichen innerhalb einer an zitierten Zeichenfolge.

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

  2. Fügen Sie schließlich ein neues Zeilenzeichen an jede kanonisierte Kopfzeile in der resultierenden Liste an. Erstellen Sie die CanonicalizedHeaders Zeichenfolge, indem Sie alle Kopfzeilen in dieser Liste in eine einzelne Zeichenfolge verketten.

Im Folgenden sehen Sie ein Beispiel für eine kanonische Headerzeichenfolge:

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

Anmerkung

Vor Der Dienstversion 2016-05-31 wurden Kopfzeilen mit leeren Werten aus der Signaturzeichenfolge weggelassen. Diese werden jetzt in CanonicalizedHeaders dargestellt, indem sie unmittelbar nach dem Doppelpunktzeichen mit der endenden neuen Zeile folgen.

Erstellen der kanonischen Ressourcenzeichenfolge

Der CanonicalizedResource Teil der Signaturzeichenfolge stellt die Speicherdiensteressource dar, die von der Anforderung adressiert wird. Jeder Teil der CanonicalizedResource Zeichenfolge, die vom URI der Ressource abgeleitet wird, sollte genau wie im URI codiert werden.

Es gibt zwei unterstützte Formate für die CanonicalizedResource Zeichenfolge:

  • Ein Format, das die Shared Key-Autorisierung 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 Shared Key und Shared Key Lite für alle Versionen des Tabellendiensts und Shared Key Lite für Version 2009-09-19 und höher der Blob- und Warteschlangendienste unterstützt. Dieses Format ist identisch mit dem Format, das mit früheren Versionen der Speicherdienste verwendet wird.

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

Wichtig

Wenn Ihr Speicherkonto mit georeplizierter Lesezugriff (RA-GRS) repliziert wird und Sie auf eine Ressource am sekundären Standort zugreifen, schließen Sie die –secondary-Bezeichnung nicht in die CanonicalizedResource Zeichenfolge ein. Der im CanonicalizedResource Zeichenfolgen-URI verwendete Ressourcen-URI sollte der URI der Ressource am primären Speicherort sein.

Anmerkung

Wenn Sie die Autorisierung für den Speicher-Emulator ausführen, wird der Kontoname zweimal in der CanonicalizedResource Zeichenfolge angezeigt. Dies wird erwartet. Wenn Sie azure-Speicherdienste autorisieren, wird der Kontoname nur einmal in der CanonicalizedResource Zeichenfolge angezeigt.

Shared Key format for 2009-09-19 and later

Dieses Format unterstützt die Shared Key-Autorisierung 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 in diesem Format wie folgt:

  1. Fügen Sie beginnend mit einer leeren Zeichenfolge (""), einen Schrägstrich (/) gefolgt vom Namen des Kontos an, auf das die Ressource 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, einschließlich des comp-Parameters, falls vorhanden.

  4. Konvertieren Sie alle Parameternamen in Kleinbuchstaben.

  5. Sortieren Sie die Abfrageparameter lexikalisch nach Dem Parameternamen in aufsteigender Reihenfolge.

  6. URL-Decodierung der einzelnen Abfrageparameternamen und -werte.

  7. Fügen Sie vor jedem Namen-Wert-Paar ein neues Zeilenzeichen (\n) ein.

  8. Fügen Sie jeden Abfrageparameternamen und -wert an die Zeichenfolge im folgenden Format an, und stellen Sie sicher, dass Sie den Doppelpunkt (:) zwischen dem Namen und dem Wert einschließen:

    parameter-name:parameter-value

  9. Wenn ein Abfrageparameter mehrere Werte aufweist, sortieren Sie alle Werte lexikalisch, und fügen Sie sie 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 kanonischen Ressourcenzeichenfolge:

  • Vermeiden Sie die Verwendung des neuen Zeilenzeichens (\n) in Werten für Abfrageparameter. Wenn sie verwendet werden muss, stellen Sie sicher, dass sie sich nicht auf das Format der kanonischen Ressourcenzeichenfolge auswirkt.

  • Vermeiden Sie die Verwendung von Kommas in Abfrageparameterwerten.

Hier sind einige Beispiele, die den CanonicalizedResource Teil der Signaturzeichenfolge zeigen, da sie aus einem bestimmten Anforderungs-URI erstellt werden können:

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 2009-09-19 und höher

Dieses Format unterstützt Shared Key und Shared Key Lite für alle Versionen des Tabellendiensts und Shared Key Lite für Version 2009-09-19 und höher der Blob- und Warteschlangendienste und Version 2014-02-14 und höher des Dateidiensts. Dieses Format ist identisch mit dem Format, das mit früheren Versionen der Speicherdienste verwendet wird. Erstellen Sie die CanonicalizedResource Zeichenfolge in diesem Format wie folgt:

  1. Fügen Sie beginnend mit einer leeren Zeichenfolge (""), einen Schrägstrich (/) gefolgt vom Namen des Kontos an, auf das die Ressource zugegriffen wird.

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

Codieren der Signatur

Rufen Sie zum Codieren der Signatur den HMAC-SHA256 Algorithmus für die UTF-8-codierte Signaturzeichenfolge auf, und codieren Sie das Ergebnis als Base64. Beachten Sie, dass Sie ihren Speicherkontoschlüssel auch base64 decodieren müssen. Verwenden Sie das folgende Format (als Pseudocode dargestellt):

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

Siehe auch