Amazon Simple Storage Service
Entwicklerhandbuch (API-Version 2006-03-01)

Signieren und Authentifizieren von REST-Anforderungen

Anmerkung

In diesem Thema werden AuthentifizierungsAnforderungen unter Verwendung von Signature Version 2 beschrieben. Amazon S3 unterstützt nun die neueste Version, Signature Version 4. Diese neueste Signatur-Version wird in allen Regionen unterstützt. Alle neuen Regionen unterstützen nach dem 30. Januar 2014 nur Signature Version 4. Weitere Informationen finden Sie unter Authentifizieren von Anforderungen (AWS Signature Version 4) in der Amazon Simple Storage Service API Reference.

Die Authentifizierung ist der Prozess, Ihre Identität gegenüber dem System nachzuweisen. Identität ist ein wichtiger Faktor in den Zugriffssteuerungsentscheidungen von Amazon S3. Anforderungen werden zum Teil basierend auf der Identität des Auftraggebers zugelassen oder abgewiesen. Das Recht, Buckets zu erstellen, ist beispielsweise für registrierte Entwickler reserviert (standardmäßig), und das Recht, Objekte in einem Bucket zu erstellen, ist für den Eigentümer des betreffenden Buckets reserviert. Als Entwickler machen Sie Anforderungen, für die diese Berechtigungen gelten müssen, deshalb müssen Sie Ihre Identität gegenüber dem System belegen, indem Sie Ihre Anforderungen authentifizieren. In diesem Abschnitt erfahren Sie mehr darüber.

Anmerkung

Der Inhalt dieses Abschnitts gilt nicht für HTTP POST. Weitere Informationen finden Sie unter Browserbasierte Uploads mit POST (AWS Signature-Version 2).

Die Amazon S3 REST API verwendet ein allgemeines HTTP-Schema basierend auf einem verschlüsselten HMAC (Hash Message Authentication Code) für die Authentifizierung. Um eine Anforderung zu authentifizieren, verknüpfen Sie zuerst ausgewählte Elemente der Anforderung, um eine Zeichenfolge zu erstellen. Anschließend verwenden Sie Ihren geheimen AWS-Zugriffsschlüssel, um den HMAC für diese Zeichenfolge zu berechnen. Informell bezeichnen wir diesen Prozess als „Signieren der Anforderung“. Wir bezeichnen die Ausgabe des HMAC-Algorithmus als die Signatur, weil sie die Sicherheitseigenschaften einer realen Signatur simuliert. Schließlich fügen Sie diese Signatur als Parameter der Anforderung hinzu. Dazu verwenden Sie die in diesem Abschnitt beschriebene Syntax.

Wenn das System eine authentifizierte Anforderung erhält, lädt es den geheimen AWS-Zugriffsschlüssel, den Sie behaupten zu haben, und verwendet ihn genau so, um aus der empfangenen Nachricht eine Signatur zu berechnen. Anschließend vergleicht es die berechnete Signatur mit der Signatur, die der Anforderer vorgezeigt hat. Stimmen die beiden Signaturen überein, schließt das System daraus, dass der Anforderer Zugriff auf den geheimen AWS-Zugriffsschlüssel hat, und damit mit der Genehmigung des Prinzipals handelt, dem der Schlüssel ausgestellt wurde. Stimmen die beiden Signaturen nicht überein, wird die Anforderung verworfen und das System antwortet mit einer Fehlermeldung.

Beispiel Authentifizierte Amazon S3 REST-Anforderung

GET /photos/puppy.jpg HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Mon, 26 Mar 2007 19:37:58 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:frJIUN8DYpKDtOLCwo//yllqDzg=

Using Temporary Security Credentials

Wenn Sie Ihre Anforderung unter Verwendung temporärer Sicherheitsanmeldeinformationen signieren (siehe Senden von Anfragen), müssen Sie das entsprechende Sicherheitstoken in Ihre Anforderung aufnehmen, indem Sie den x-amz-security-token-Header hinzufügen.

Wenn Sie unter Verwendung der AWS Security Token Service API temporäre Sicherheitsanmeldeinformationen erhalten haben, beinhaltet die Antwort temporäre Sicherheitsanmeldeinformationen und ein Sitzungstoken. Sie stellen den Wert des Sitzungstoken im x-amz-security-token-Header bereit, wenn Sie Anforderungen an Amazon S3 senden. Informationen zur AWS Security Token Service-API, die von IAM bereitgestellt wird, finden Sie unter Aktion im AWS Security Token Service API Reference-Handbuch.

Der Authentication-Header

Die Amazon S3-REST-API verwendet den HTTP-Standard-Header Authorization, um Authentifizierungsinformationen zu übergeben. (Der Name des Standardheaders ist unglücklich gewählt, weil er eine Authentifizierung weitergibt, keine Autorisierung.) Unter dem Amazon S3-Authentifizierungsschema hat der Authorization-Header die folgende Form:

Authorization: AWS AWSAccessKeyId:Signature

Entwicklern wird eine AWS-Zugriffsschlüssel-ID und ein geheimer AWS-Zugriffsschlüssel ausgestellt, wenn sie sich anmelden. Für die Anforderungsauthentifizierung identifiziert das AWSAccessKeyId-Element die Zugriffsschlüssel-ID, die für die Berechnung der Signatur verwendet wurde, und indirekt für den Entwickler steht, der die Anforderung gestellt hat.

Das Signature-Element ist das RFC 2104 HMAC-SHA1 ausgewählter Elemente aus der Anforderung, der Signature-Teil des Authorization-Headers unterscheidet sich deshalb zwischen verschiedenen Anforderungen. Wenn die vom System berechnete Anforderungssignatur mit der in der Anforderung enthaltenen Signature übereinstimmt, hat der Auftraggeber belegt, dass er den geheimen AWS-Zugriffsschlüssel besitzt. die Anforderung wird unter der Identität verarbeitet, und mit der Genehmigung des Entwicklers, dem der Schlüssel ausgestellt wurde.

Die folgende Pseudogrammatik verdeutlicht den Aufbau des Authorization-Anforderungs-Headers. (In dem Beispiel steht \n für den Unicode-Code U+000A, häufig auch als Newline bezeichnet.)

Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature; Signature = Base64( HMAC-SHA1( YourSecretAccessKey, UTF-8-Encoding-Of( StringToSign ) ) ); StringToSign = HTTP-Verb + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Date + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource; CanonicalizedResource = [ "/" + Bucket ] + <HTTP-Request-URI, from the protocol name up to the query string> + [ subresource, if present. For example "?acl", "?location", "?logging", or "?torrent"]; CanonicalizedAmzHeaders = <described below>

HMAC-SHA1 ist ein von RFC 2104 - Keyed-Hashing for Message Authentication definierter Algorithmus. Der Algorithmus nimmt zwei Byte-Zeichenfolgen als Eingabe entgegen, einen Schlüssel und eine Nachricht. Verwenden Sie für die Authentifizierung von Amazon S3-Anforderungen Ihren geheimen AWS-Zugriffsschlüssel (YourSecretAccessKey) als Schlüssel und die UTF-8-Codierung von StringToSign als Nachricht. Die Ausgabe von HMAC-SHA1 ist ebenfalls eine Byte-Zeichenfolge, der sogenannte Digest. Der Signature-Anforderungsparameter wird durch eine Base64-Codierung dieses Digest erstellt.

Anforderung einer Kanonisierung für die Signatur

Wenn das System eine authentifizierte Anforderung erhält, vergleicht es die berechnete Anforderungssignatur mit der in der Anforderung im StringToSign breitgestellten Signatur, wie bereits beschrieben. Aus diesem Grund müssen Sie die Signatur nach derselben Methode berechnen, wie Amazon S3 sie verwendet. Wir bezeichnen diesen Prozess, bei dem eine Anforderung in die für die Signatur vereinbarte Form gebracht wird, als Kanonisierung.

Erstellen des CanonicalizedResource-Elements

CanonicalizedResource stellt die Amazon S3-Ressource dar, die das Ziel der Anforderung ist. Für eine REST-Anforderung erstellen Sie sie wie folgt:

Starten des Prozesses

1

Beginnen Sie mit einer leeren Zeichenfolge ("").

2

Wenn die Anforderung unter Verwendung des HTTP Host-Headers (virtueller gehosteter Stils) einen Bucket angibt, fügen Sie den Bucket-Namen mit vorgestelltem "/" an (z. B. „/bucketname“). Für Anforderungen im Pfad-Stil und Anforderungen, die an keinen spezifischen Bucket gerichtet sind, machen Sie nichts. Weitere Informationen zum Wiederholen von Anforderungen finden Sie unter Virtuelles Hosting bei Buckets.

Für eine Anforderung mit virtuell gehostetem Stil „https://johnsmith.s3.amazonaws.com/photos/puppy.jpg“ ist die CanonicalizedResource gleich „/johnsmith“.

Für eine Anforderung mit Pfad-Stil „https://s3.amazonaws.com/johnsmith/photos/puppy.jpg“ ist die CanonicalizedResource gleich „“.

3

Fügen Sie den Pfad-Abschnitt der nicht decodierten HTTP Anforderungs-URI bis zur (aber nicht inklusive der) Abfragezeichenfolge ein.

Für eine Anforderung mit virtuell gehostetem Stil „https://johnsmith.s3.amazonaws.com/photos/puppy.jpg“ ist die CanonicalizedResource gleich „/johnsmith/photos/puppy.jpg“.

Für eine Anforderung mit Pfad-Stil „https://s3.amazonaws.com/johnsmith/photos/puppy.jpg“ ist die CanonicalizedResource gleich „/johnsmith/photos/puppy.jpg“. An dieser Stelle ist der CanonicalizedResource für Anforderungen mit virtuell gehostetem Stil und Pfad-Stil gleich.

Im Fall einer Anforderung, die sich nicht an einen Bucket richtet, wie GET Service, fügen Sie „/“ an.

4

Wenn sich die Anforderung an eine Subressource richtet, wie beispielsweise ?versioning, ?location, ?acl, ?torrent, ?lifecycle oder ?versionid, fügen Sie die Subressource an, gegebenenfalls ihren Wert und das Fragezeichen. Beachten Sie, dass mehrere Subressourcen alphabetisch nach dem Namen der Subressource sortiert und durch '&' voneinander getrennt werden müssen, z. B. ?acl&versionId=value.

Die Subressourcen, die bei der Erstellung des CanonicalizedResource-Elements angegeben werden müssen, sind acl, lifecycle, location, logging, notification, partNumber, policy, requestPayment, torrent, uploadId, uploads, versionId, versioning, versions und website.

Wenn die Anforderung Abfragezeichenfolgen-Parameter angibt, die die Antwortheader-Werte überschreiben (siehe Get Object), fügen Sie die Abfragezeichenfolgen-Parameter und ihre Werte an. Bei einer Signatur codieren Sie diese Werte nicht. Bei einer Anforderung dagegen müssen Sie diese Parameterwerte codieren. Die Abfrageparameter in einer GET-Anforderung sind unter anderem response-content-type, response-content-language, response-expires, response-cache-control, response-content-disposition und response-content-encoding.

Wenn Sie die CanonicalizedResource für eine Löschanforderung für mehrere Objekte erstellen, muss der Abfrage-Zeichenfolgenparameter delete angegeben werden.

Elemente der CanonicalizedResource, die aus der HTTP Request-URI stammen, sollten genauso signiert werden, wie sie in der HTTP-Anforderung erscheinen, einschließlich der Metazeichen der URL-Codierung.

Möglicherweise unterschiedet sich die CanonicalizedResource von der HTTP Anforderungs-URI. Wenn Ihre Anforderung den HTTP-Header Host verwendet, um einen Bucket anzugeben, erscheint der Bucket nicht in der HTTP Anforderungs-URI. Die CanonicalizedResource beinhaltet den Bucket jedoch weiterhin. Abfrage-Zeichenfolgenparameter können auch in der Anforderungs-URI erscheinen, sind aber nicht in der CanonicalizedResource enthalten. Weitere Informationen finden Sie unter Virtuelles Hosting bei Buckets.

Erstellen des CanonicalizedAmzHeaders-Elements

Um den CanonicalizedAmzHeaders-Teil von StringToSign zu erstellen, wählen Sie alle HTTP-Anforderungsheader aus, die mit 'x-amz-' beginnen (über einen Vergleich, der die Groß-/Kleinschreibung nicht berücksichtigt), und gehen nach dem folgenden Verfahren vor.

CanonicalizedAmzHeaders-Verfahren

1 Wandeln Sie jeden HTTP-Headernamen in Kleinbuchstaben um. Beispielsweise wird 'X-Amz-Date' zu 'x-amz-date'.
2 Sortieren Sie die Header alphabetisch nach dem Headernamen.
3 Kombinieren Sie Headerfelder mit demselben Namen zu einem „header-name:comma-separated-value-list“-Paar, wie von RFC 2616 Abschnitt 4.2 vorgegeben, ohne Leerzeichen zwischen den Werten. Die beiden Metadaten-Header 'x-amz-meta-username: fred' und 'x-amz-meta-username: barney' würden beispielsweise zu einem einzigen Header 'x-amz-meta-username: fred,barney' zusammengefasst.
4 „Falten“ Sie lange Header auf, die sich über mehrere Zeilen erstrecken (wie durch RFC 2616 Abschnitt 4.2 erlaubt), indem Sie den faltenden Whitespace (einschließlich von Neue-Zeile-Zeichen) durch ein einzelnes Leerzeichen ersetzen.
5 Entfernen Sie Whitespace um den Doppelpunkt im Header. Beispielsweise würde der Header 'x-amz-meta-username: fred,barney' zu 'x-amz-meta-username:fred,barney'
6 Schließlich fügen Sie jedem kanonisierten Header in der Ergebnisliste ein Neue-Zeile-Zeichen (U+000A) hinzu. Erstellen Sie das CanonicalizedResource-Element, indem Sie alle Header in dieser Liste zu einer einzelnen Zeichenfolge zusammenfassen.

Positionale vs. benannte StringToSign-Elemente von HTTP-Headern

Die ersten Header-Elemente von StringToSign (Content-Type, Date und Content-MD5) sind von ihrer Art her positionsbezogen. StringToSign fügt nicht die Namen dieser Header, sondern nur ihre Werte aus der Anforderung ein. Im Gegensatz dazu sind die 'x-amz-'-Elemente benannt. Sowohl die Header-Namen als auch die Header-Werte erscheinen in StringToSign.

Wenn ein positionaler Header, der in der Definition von StringToSign vorgegeben ist, in Ihrer Anforderung nicht vorhanden ist (z. B. sind Content-Type oder Content-MD5 optionale für PUT-Anforderungen und sinnlos für GET-Anforderungen), setzen Sie in dieser Position die leere Zeichenfolge ("") ein.

Zeitstempel-Anforderung

Ein gültiger Zeitstempel (unter Verwendung des HTTP-Headers Date oder einer x-amz-date-Alternative) ist zwingend erforderlich für authentifizierte Anforderungen. Darüber hinaus muss der Client-Zeitstempel in einer authentifizierten Anforderung innerhalb eines Zeitraums von 15 Minuten zur Amazon S3-Systemzeit liegen, wenn die Anforderung empfangen wird. Wenn dies nicht der Fall ist, schlägt die Anforderung mit RequestTimeTooSkewed-Fehlercode fehl. Diese Einschränkungen sollen verhindern, dass abgefangene Anforderungen böswillig wiederholt werden. Für einen strengeren Schutz gegen ein Abhören transportieren Sie authentifizierte Anforderung mit HTTPS.

Anmerkung

Die Auswertungsbeschränkung im Hinblick auf das Anforderungsdatum gilt nur für authentifizierte Anforderungen, die keine Abfrage-String-Authentifizierung verwenden. Weitere Informationen finden Sie unter Alternative zur Authentifizierung der Abfragezeichenfolge.

Einige HTTP-Client-Bibliotheken unterstützen die Möglichkeit nicht, den Date-Header für eine Anforderung einzurichten. Wenn Sie Probleme damit haben, den Wert des 'Date'-Headers in kanonisierte Header aufzunehmen, können Sie den Zeitstempel für die Anforderung stattdessen auch mit einem 'x-amz-date'-Header einrichten. Der Wert des x-amz-date-Headers muss in einem der von RFC 2616 vorgegebenen Formate vorliegen (http://www.ietf.org/rfc/rfc2616.txt). Wenn in einer Anforderung ein x-amz-date-Header vorhanden ist, ignoriert das System bei der Berechnung der Anforderungssignatur jeden Date-Header. Wenn Sie also den x-amz-date-Header aufnehmen, verwenden Sie die leere Zeichenfolge für Date, wenn Sie den StringToSign erstellen. Ein Beispiel finden Sie im nächsten Abschnitt.

Beispiel für die Authentifizierung

Die Beispiele in diesem Abschnitt verwenden die (nicht funktionierenden) Anmeldeinformationen aus der folgenden Tabelle.

Parameter Value
AWSAccessKeyId AKIAIOSFODNN7EXAMPLE
AWSSecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

In den StringToSigns des Beispiels ist die Formatierung nicht relevant, und \n steht für den Unicode-Punkt U+000A, allgemein als Neue-Zeile-Zeichen bezeichnet. Außerdem verwenden die Beispiele "+0000", um die Zeitzone anzugeben. Sie können die Zeitzone stattdessen mit "GMT" angeben, aber in den Beispielen werden andere Signaturen verwendet.

Object GET

Dieses Beispiel ruft ein Objekt aus dem Bucket johnsmith ab.

Anforderung StringToSign
GET /photos/puppy.jpg HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:36:42 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: bWq2s1WEIj+Ydj0vQ697zp+IXMU=
GET\n \n \n Tue, 27 Mar 2007 19:36:42 +0000\n /johnsmith/photos/puppy.jpg

Beachten Sie, dass die CanonicalizedResource den Bucket-Namen beinhaltet, die HTTP Anforderungs-URI dagegen nicht. (Der Bucket wird vom Host-Header spezifiziert.)

Object PUT

Dieses Beispiel schreibt ein Objekt in den Bucket johnsmith.

Anforderung StringToSign
PUT /photos/puppy.jpg HTTP/1.1 Content-Type: image/jpeg Content-Length: 94328 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 21:15:45 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: MyyxeRY7whkBe+bq8fHCL/2kKUg=
PUT\n \n image/jpeg\n Tue, 27 Mar 2007 21:15:45 +0000\n /johnsmith/photos/puppy.jpg

Beachten Sie den Content-Type-Header in der Anforderung und im StringToSign. Beachten Sie außerdem, dass Content-MD5 im StringToSign leer ist, weil es in der Anforderung nicht vorhanden ist.

Liste

Dieses Beispiel listet den Inhalt des Buckets johnsmith auf.

Anforderung StringToSign
GET /?prefix=photos&max-keys=50&marker=puppy HTTP/1.1 User-Agent: Mozilla/5.0 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:42:41 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: htDYFYduRNen8P9ZfE/s9SuKy0U=
GET\n \n \n Tue, 27 Mar 2007 19:42:41 +0000\n /johnsmith/

Beachten Sie den abschließenden Schrägstrich an der CanonicalizedResource sowie das Fehlen von Abfrage-Zeichenfolgenparametern.

Fetch

Dieses Beispiel lädt die Zugriffskontrollrichtlinien-Subressource für den Bucket johnsmith.

Anforderung StringToSign
GET /?acl HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:44:46 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: c2WLPFtWHVgbEmeEG93a4cG37dM=
GET\n \n \n Tue, 27 Mar 2007 19:44:46 +0000\n /johnsmith/?acl

Beachten Sie, wie der Subressourcen-Abfragezeichenfolgenparameter in die CanonicalizedResource aufgenommen wird.

Löschen

Dieses Beispiel löscht ein Objekt unter Verwendung des Pfad-Stils und der Date-Alternative aus dem Bucket' 'johnsmith'.

Anforderung StringToSign
DELETE /johnsmith/photos/puppy.jpg HTTP/1.1 User-Agent: dotnet Host: s3.amazonaws.com Date: Tue, 27 Mar 2007 21:20:27 +0000 x-amz-date: Tue, 27 Mar 2007 21:20:26 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:lx3byBScXR6KzyMaifNkardMwNk=
DELETE\n \n \n Tue, 27 Mar 2007 21:20:26 +0000\n /johnsmith/photos/puppy.jpg

Beachten Sie, wie wir die alternative Methode 'x-amz-date' verwendet haben, um das Datum anzugeben (beispielsweise weil unsere Client-Bibliothek verhindert hat, dass wir das Datum festgelegt haben). In diesem Fall hat x-amz-date Vorrang vor dem Date-Header. Aus diesem Grund muss der Datumseintrag in der Signatur den Wert des x-amz-date-Headers enthalten.

Hochladen

Dieses Beispiel lädt ein Objekt in einen virtuell gehosteten Bucket mit CNAME-Stil mit Metadaten.

Anforderung StringToSign
PUT /db-backup.dat.gz HTTP/1.1 User-Agent: curl/7.15.5 Host: static.johnsmith.net:8080 Date: Tue, 27 Mar 2007 21:06:08 +0000 x-amz-acl: public-read content-type: application/x-download Content-MD5: 4gJE4saaMU4BqNR0kLY+lw== X-Amz-Meta-ReviewedBy: joe@johnsmith.net X-Amz-Meta-ReviewedBy: jane@johnsmith.net X-Amz-Meta-FileChecksum: 0x02661779 X-Amz-Meta-ChecksumAlgorithm: crc32 Content-Disposition: attachment; filename=database.dat Content-Encoding: gzip Content-Length: 5913339 Authorization: AWS AKIAIOSFODNN7EXAMPLE: ilyl83RwaSoYIEdixDQcA4OnAnc=
PUT\n 4gJE4saaMU4BqNR0kLY+lw==\n application/x-download\n Tue, 27 Mar 2007 21:06:08 +0000\n x-amz-acl:public-read\n x-amz-meta-checksumalgorithm:crc32\n x-amz-meta-filechecksum:0x02661779\n x-amz-meta-reviewedby: joe@johnsmith.net,jane@johnsmith.net\n /static.johnsmith.net/db-backup.dat.gz

Beachten Sie, wie die 'x-amz-'-Header sortiert, von Whitespaces befreit und in Kleinbuchstaben umgewandelt wurden. Beachten Sie außerdem, dass mehrere Header mit demselben Namen unter Verwendung von Kommas zum Trennen der Werte verknüpft wurden.

Beachten Sie, wie nur die HTTP-Header Content-Type und Content-MD5 in StringToSign erscheinen. Die anderen Content-*-Header erscheinen nicht.

Beachten Sie ebenfalls, dassCanonicalizedResource den Bucket-Namen beinhaltet, die HTTP Anforderungs-URI dagegen nicht. (Der Bucket wird vom Host-Header spezifiziert.)

Alle meine Buckets auflisten

Anforderung StringToSign
GET / HTTP/1.1 Host: s3.amazonaws.com Date: Wed, 28 Mar 2007 01:29:59 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:qGdzdERIC03wnaRNKh6OqZehG9s=
GET\n \n \n Wed, 28 Mar 2007 01:29:59 +0000\n /

Unicode-Schlüssel

Anforderung StringToSign
GET /dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re HTTP/1.1 Host: s3.amazonaws.com Date: Wed, 28 Mar 2007 01:49:49 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:DNEZGsoieTZ92F3bUfSPQcbGmlM=
GET\n \n \n Wed, 28 Mar 2007 01:49:49 +0000\n /dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re

Anmerkung

Die Elemente in StringToSign, die von der Anforderungs-URI abgeleitet wurden, werden unverändert übernommen, einschließlich der URL-Codierung und der Großschreibung.

Probleme mit dem Signieren von REST-Anforderungen

Wenn die Authentifizierung einer REST-Anforderung fehlschlägt, reagiert das System mit einem XML-Fehlerdokument auf die Anforderung. Die in diesem Fehlerdokument enthaltene Information soll Entwicklern helfen, das Problem zu diagnostizieren. Insbesondere erkennen Sie an dem StringToSign-Element des SignatureDoesNotMatch-Fehlerdokuments genau, welche Anforderungs-Kanonisierung das System verwendet.

Einige Toolkits fügen stillschweigend Header ein, die Sie zuvor nicht kennen, wie beispielsweise den Header Content-Type bei einem PUT. In den meisten dieser Fälle bleibt der Wert des eingefügten Headers konstant, sodass Sie fehlende Header unter Verwendung von Tools wie Ethereal oder tcpmon erkennen können.

Alternative zur Authentifizierung der Abfragezeichenfolge

Einige Anforderungstypen können Sie authentifizieren, indem Sie die angeforderten Informationen als Abfragezeichenfolgenparameter übergeben, statt den HTTP-Header Authorization zu verwenden. Das ist praktisch, um direkten Zugriff durch einen Browser von Dritten auf Ihre privaten Amazon S3-Daten zu ermöglichen, ohne dass die Anforderung über einen Proxy geschickt wird. Die Idee besteht in der Konstruierung einer „vorsignierten“ Anforderung und ihrer Codierung als einer URL, die vom Browser eines Endbenutzers geladen werden kann. Darüber hinaus können Sie eine vorsignierte Anforderung durch die Angabe einer Ablaufzeit begrenzen.

Anmerkung

Beispiele für die Verwendung von AWS SDKs zum Generieren vorsignierter URLs finden Sie unter Ein Objekt mit anderen teilen.

Erstellen einer Signatur

Das folgende Beispiel zeigt eine authentifizierte Amazon S3 REST-Anforderung mit Abfragezeichenfolge.

GET /photos/puppy.jpg ?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Mon, 26 Mar 2007 19:37:58 +0000

Die Authentifizierungsmethode für die Abfragezeichenkette benötigt keine spezifischen HTTP-Header. Stattdessen werden die erforderlichen Authentifizierungselemente als Abfragezeichenfolgenparameter angegeben:

Abfragezeichenfolgen-Parametername Beispielwert Beschreibung
AWSAccessKeyId AKIAIOSFODNN7EXAMPLE Ihre AWS-Zugriffsschlüssel-ID. Gibt den geheimen AWS-Zugriffsschlüssel an, der verwendet wurde, um die Anforderung zu signieren, und indirekt die Identität des Entwicklers angibt, der die Anforderung gestellt hat.
Expires 1141889120 Die Zeit, wann die Signatur abläuft, angegeben als die Anzahl der Sekunden, die seit dem 1. Januar 1970 00:00:00 UTC verstrichen sind. Eine Anforderung, die nach dieser Zeit empfangen wird (abhängig vom Server), wird abgelehnt.
Signature vjbyPxybdZaNmGa%2ByT272YEAiv4%3D Die URL-Codierung der Base64-Codierung des HMAC-SHA1 für StringToSign.

Die Methode zur Authentifizierung der Abfragezeichenfolge unterscheidet sich leicht von der üblichen Methode, aber nur im Format des Signature-Anforderungsparameters und des StringToSign-Elements. Die folgende Pseudogrammatik verdeutlicht die Authentifizierungsmethode für die Abfragezeichenfolge.

Signature = URL-Encode( Base64( HMAC-SHA1( YourSecretAccessKey, UTF-8-Encoding-Of( StringToSign ) ) ) ); StringToSign = HTTP-VERB + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Expires + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource;

YourSecretAccessKey ist die ID des geheimen AWS-Zugriffsschlüssels, die Ihnen Amazon zuordnet, wenn Sie sich als Amazon Web Service-Entwickler anmelden. Beachten Sie, wie die Signature URL-codiert wird, damit sie für die Platzierung im Abfragestring geeignet ist. Beachten Sie auch, dass in StringToSign das HTTP-Positionselement Date durch Expires ersetzt wurde. CanonicalizedAmzHeaders und CanonicalizedResource sind gleich.

Anmerkung

In der Methode für die Abfrage-String-Authentifizierung verwenden Sie den Header Date oder x-amz-date request nicht, wenn Sie die zu signierende Zeichenfolge berechnen.

Abfrage-String-Authentifizierung

Anforderung StringToSign
GET /photos/puppy.jpg?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE& Signature=NpgCjnDzrM%2BWFzoENXmpNDUsSn8%3D& Expires=1175139620 HTTP/1.1 Host: johnsmith.s3.amazonaws.com
GET\n \n \n 1175139620\n /johnsmith/photos/puppy.jpg

Wir gehen davon aus, dass ein Browser bei einer GET-Anforderung keinen Content-MD5- oder Content-Type-Header bereitstellt, und auch keine x-amz--Header einrichten, diese Teile von StringToSign bleiben deshalb leer.

Verwendung der Base64-Codierung

Signaturen von HMAC-Anforderungen müssen mit Base64 codiert werden. Die Base64-Codierung wandelt die Signatur in einen einfachen ASCII-String um, der der Anforderung hinzugefügt werden kann. Zeichen, die in der Signatur erscheinen können, wie beispielsweise Plus (+), Schrägstrich (/) oder Gleichheitszeichen (=), müssen wie in einer URI codiert werden. Enthält beispielsweise der Authentifizierungscode ein Plussymbol (+), codieren Sie es in der Anforderung als &2B. Einen Schrägstrich codieren Sie als &2F, ein Gleichheitszeichen als %3D.

Beispiele für die Base64-Codierung finden Sie in den Beispiel für die Authentifizierung für Amazon S3.