Amazon Web Services
Allgemeine Referenz (Version 1.0)

Aufgabe 1: Erstellen einer kanonischen Anforderung für Signature Version 4

Um den Signaturprozess zu starten, erstellen Sie eine Zeichenfolge, die Informationen aus Ihrer Anforderung in einem standardisierten (kanonischen) Format enthält. Auf diese Weise wird sichergestellt, dass bei Erhalt der Anforderung bei AWS die gleiche Signatur berechnet werden kann, die Sie berechnet haben.

Befolgen Sie die hier genannten Schritte zum Erstellen einer kanonischen Version der Anforderung. Andernfalls werden Ihre Version und die von AWS berechnete Version nicht übereinstimmen und die Anforderung wird abgelehnt.

Das folgende Beispiel zeigt den Pseudocode zum Erstellen einer kanonischen Anforderung.

Beispiel Pseudocode einer kanonischen Anforderung

CanonicalRequest = HTTPRequestMethod + '\n' + CanonicalURI + '\n' + CanonicalQueryString + '\n' + CanonicalHeaders + '\n' + SignedHeaders + '\n' + HexEncode(Hash(RequestPayload))

In diesem Pseudocode stellt Hash eine Funktion dar, die einen Nachrichtendigest erzeugt, in der Regel SHA-256. (Später im Prozess geben Sie an, welchen Hashing-Algorithmus Sie verwenden.) HexEncode steht für eine Funktion, die die Basis-16-Kodierung des Digest in Kleinbuchstaben zurückgibt. Zum Beispiel gibt HexEncode("m") den Wert 6d und nicht 6D zurück. Jedes Eingabebyte muss als genau zwei Hexadezimalzeichen dargestellt werden.

Signature Version 4 setzt nicht voraus, dass Sie eine bestimmte Zeichenkodierung für die Kodierung der kanonischen Anforderung verwenden. Bei einigen AWS-Services ist jedoch möglicherweise eine spezielle Kodierung erforderlich. Weitere Informationen finden Sie in der Dokumentation zu dem jeweiligen Service.

Die folgenden Beispiele zeigen, wie eine Anforderung im kanonischen Format für IAM erstellt wird. Die ursprüngliche Anforderung kann wie folgt aussehen, wenn sie vom Client an AWS gesendet wird, mit der Ausnahme, dass dieses Beispiel noch nicht die Signierinformationen enthält.

Beispiel request

GET https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08 HTTP/1.1 Host: iam.amazonaws.com Content-Type: application/x-www-form-urlencoded; charset=utf-8 X-Amz-Date: 20150830T123600Z

In der vorangegangenen Beispielanforderung wird eine GET-Anforderung (GET-Methode) verwendet, die einen ListUsers-API-Aufruf (Aktionsaufruf) an AWS Identity and Access Management (den Host) startet. Diese Aktion übernimmt den Parameter Version.

Um eine kanonische Anforderung zu erstellen, verbinden Sie die folgenden Komponenten aus jedem Schritt zu einer einzelnen Zeichenfolge:

  1. Beginnen Sie mit der HTTP-Anforderungsmethode (GET, PUTPOST usw.), gefolgt von einem Zeilenumbruchzeichen.

    Beispiel Anforderungsmethode

    GET
  2. Fügen Sie den kanonische URI-Parameter hinzu, gefolgt von einem Zeilenumbruchzeichen. Der kanonische URI ist die URI-kodierte Version des absoluten Pfadbestandteils des URI. Dies ist alles in der URI vom HTTP-Host bis zum Fragezeichen ("?"), mit dem die Abfragezeichenfolgenparameter (falls vorhanden) beginnen.

    Normalisieren Sie die URI-Pfade gemäß RFC 3986. Entfernen Sie redundante und relative Pfadbestandteile. Jedes Pfadsegment muss URI-kodiert sein.

    Beispiel kanonische URI mit Kodierung

    /documents%20and%20settings/

    Anmerkung

    Als Ausnahme gilt hier, dass Sie keine URI-Pfade für Anforderungen in Amazon S3 normalisieren. Wenn Sie zum Beispiel über einen Bucket mit einem Objekt namens my-object//example//photo.user verfügen, verwenden Sie diesen Pfad. Wird der Pfad zu my-object/example/photo.user normalisiert, schlägt die Anforderung fehl. Weitere Informationen finden Sie unter Aufgabe 1: Erstellen einer kanonischen Anforderung im Amazon Simple Storage Service API Reference.

    Wenn der absolute Pfad leer ist, verwenden Sie einen Schrägstrich (/). In der IAM-Beispielanforderung folgt auf den Host im URI nichts, also ist der absolute Pfad leer.

    Beispiel kanonische URI

    /
  3. Fügen Sie die kanonische Abfragezeichenfolge hinzu, gefolgt von einem Zeilenumbruchzeichen. Wenn die Anforderung keine Abfragezeichenfolge enthält, verwenden Sie eine leere Zeichenfolge (d. h. eine Leerzeile). Die Beispielanforderung enthält die folgende Abfragezeichenfolge.

    Beispiel kanonische Abfragezeichenfolge

    Action=ListUsers&Version=2010-05-08

    Führen Sie zum Erstellen der kanonischen Abfragezeichenfolge die folgenden Schritte aus:

    1. Sortieren Sie die Parameternamen nach Zeichencodepunkt in aufsteigender Reihenfolge. Beispiel: Ein Parametername, der mit dem Großbuchstaben "F" beginnt, steht vor einem Parameternamen, der mit einem kleinen Buchstaben "b" beginnt.

    2. Führen Sie eine URI-Kodierung für jeden Parameternamen und -wert nach folgenden Regeln durch:

      • Fügen Sie keine URI-Kodierung für die nicht reservierten Zeichen durch, die von RFC 3986 definiert sind: A-Z, a-z, 0-9, Bindestrich (-), Unterstrich (_), Punkt ( . ) und Tilde ( ~ ).

      • Versehen Sie alle anderen Zeichen mit Prozentcode (%XY), wobei X und Y für Hexadezimalzeichen, d. h. 0-9 und die Großbuchstaben A-F, stehen. Beispielsweise müssen Leerzeichen mit %20 kodiert werden (nicht mit "+" wie bei einigen Kodierungssystemen) und erweiterte UTF-8-Zeichen müssen im Format %XY%ZA%BC vorliegen.

    3. Erstellen Sie die kanonische Abfragezeichenfolge beginnend mit dem ersten Parameternamen in der sortierten Liste.

    4. Fügen Sie für jeden Parameter den URI-kodierten Parameternamen an, gefolgt vom Gleichheitszeichen (=), gefolgt vom URI-kodierten Parameterwert. Verwenden Sie eine leere Zeichenfolge für Parameter ohne Wert.

    5. Fügen Sie das kaufmännische Und-Zeichen (&) nach jedem Parameterwert an, mit Ausnahme des letzten Wertes in der Liste.

    Eine Option für die Abfrage-API ist, alle Anforderungsparameter in die Abfragezeichenfolge einzufügen. Sie können so z. B. bei Amazon S3 vorgehen, um eine vorsignierte URL zu erstellen. In diesem Fall muss die kanonische Abfragezeichenfolge nicht nur die Parameter für die Anforderung enthalten, sondern auch die Parameter, die als Bestandteil des Signaturprozesses verwendet werden, d. h. Hash-Algorithmus, Umfang der Anmeldeinformationen, Datum und signierte Headerparameter.

    Das folgende Beispiel zeigt eine Abfragezeichenfolge, die Authentifizierungsinformationen enthält. Das Beispiel ist für eine bessere Lesbarkeit mit Zeilenumbrüchen formatiert. Die kanonische Abfragezeichenfolge in Ihrem Code muss aber eine durchgehende Textzeile sein.

    Beispiel Authentifizierungsparameter in einer Abfragezeichenfolge

    Action=ListUsers& Version=2010-05-08& X-Amz-Algorithm=AWS4-HMAC-SHA256& X-Amz-Credential=AKIDEXAMPLE%2F20150830%2Fus-east-1%2Fiam%2Faws4_request& X-Amz-Date=20150830T123600Z& X-Amz-SignedHeaders=content-type%3Bhost%3Bx-amz-date

    Weitere Informationen zu Authentifizierungsparametern finden Sie unter Aufgabe 2: Erstellen einer zu signierenden Zeichenfolge für Signature Version 4.

    Anmerkung

    Sie können temporäre Sicherheitsanmeldeinformationen von der AWS Security Token Service (AWS STS) zum Signieren einer Anforderung verwenden. Der Prozess ist der gleiche wie bei dauerhaft gültigen Anmeldeinformationen. Wenn Sie aber die Signierinformationen zur Abfragezeichenfolge hinzufügen, müssen Sie einen zusätzlichen Abfrageparameter für das Sicherheits-Token hinzufügen. Der Parametername lautet X-Amz-Security-Token und der Wert des Parameters ist der URI-kodierte Sitzungs-Token (die Zeichenfolge, die Sie von AWS STS mit den temporären Sicherheitsanmeldeinformationen erhalten haben).

    Bei einigen Services müssen Sie den Abfrageparameter X-Amz-Security-Token in die kanonische (signierte) Abfragezeichenfolge aufnehmen. Bei anderen Services fügen Sie den Parameter X-Amz-Security-Token am Ende hinzu, nachdem Sie die Signatur berechnet haben. Weitere Informationen finden Sie in der API-Referenzdokumentation für diesen Service.

  4. Fügen Sie die kanonischen Header hinzu, gefolgt von einem Zeilenumbruchzeichen. Die kanonischen Header bestehen aus einer Liste aller HTTP-Header, die Sie mit der signierten Anforderung einfügen.

    Sie müssen mindestens den host-Header einfügen. Standardheader wie content-type sind optional. Verschiedene Services erfordern möglicherweise jeweils andere Header.

    Beispiel kanonische Header

    content-type:application/x-www-form-urlencoded; charset=utf-8\n host:iam.amazonaws.com\n x-amz-date:20150830T123600Z\n

    Um die Liste der kanonischen Header zu erstellen, konvertieren Sie alle Headernamen in Kleinbuchstaben und entfernen Sie Leerzeichen am Anfang und am Ende. Konvertieren Sie aufeinanderfolgende Leerzeichen im Headerwert in ein einzelnes Leerzeichen.

    Der folgende Pseudocode beschreibt, wie die Liste der kanonischen Header erstellt wird:

    CanonicalHeaders = CanonicalHeadersEntry0 + CanonicalHeadersEntry1 + ... + CanonicalHeadersEntryN CanonicalHeadersEntry = Lowercase(HeaderName) + ':' + Trimall(HeaderValue) + '\n'

    Lowercase ist eine Funktion, die alle Zeichen in Kleinbuchstaben umwandelt. Die Funktion Trimall entfernt überschüssige Leerzeichen vor und nach den Werten und konvertiert außerdem aufeinanderfolgende Leerzeichen in ein einzelnes Leerzeichen.

    Erstellen Sie die Liste der kanonischen Header durch Sortieren der Header (in Kleinbuchstaben) nach Zeichencode und arbeiten Sie dann die Headernamen durch. Erstellen Sie jeden Header gemäß den folgenden Regeln:

    • Fügen Sie den Headernamen in Kleinbuchstaben an, gefolgt von einem Doppelpunkt.

    • Fügen Sie eine durch Komma getrennte Liste der Werte für diesen Header an. Sortieren Sie nicht die Werte in Headern mit mehreren Werten.

    • Fügen Sie eine neue Zeile an ("\n").

    In den folgenden Beispielen werden komplexere Header mit ihrer kanonischen Form verglichen:

    Beispiel ursprüngliche Header

    Host:iam.amazonaws.com\n Content-Type:application/x-www-form-urlencoded; charset=utf-8\n My-header1:    a   b   c \n X-Amz-Date:20150830T123600Z\n My-Header2:    "a   b   c" \n

    Beispiel kanonische Form

    content-type:application/x-www-form-urlencoded; charset=utf-8\n host:iam.amazonaws.com\n my-header1:a b c\n my-header2:"a b c"\n x-amz-date:20150830T123600Z\n

    Anmerkung

    Auf jeden Header folgt ein Zeilenumbruchzeichen. Dies bedeutet, dass auch die fertige Liste mit einem Zeilenumbruchzeichen endet.

    In der kanonischen Form wurden die folgenden Änderungen vorgenommen:

    • Die Headernamen wurden in Kleinbuchstaben umgewandelt.

    • Die Header wurden nach Zeichencode sortiert.

    • Die Leerzeichen am Anfang und Ende wurden von den my-header1- und my-header2-Werten entfernt.

    • Aufeinanderfolgende Leerzeichen in a b c wurden in ein einzelnes Leerzeichen für die Werte my-header1 und my-header2 konvertiert.

    Anmerkung

    Sie können temporäre Sicherheitsanmeldeinformationen von der AWS Security Token Service (AWS STS) zum Signieren einer Anforderung verwenden. Der Prozess ist der gleiche wie bei der Verwendung dauerhaft gültiger Anmeldeinformationen. Wenn Sie aber Signierinformationen in den Authorization-Header einfügen, müssen Sie einen zusätzlichen HTTP-Header für den Sicherheits-Token hinzufügen. Der Headername lautet X-Amz-Security-Token und der Wert des Headers ist der Sitzungs-Token (die Zeichenfolge, die Sie von AWS STS mit den temporären Sicherheitsanmeldeinformationen erhalten haben).

  5. Fügen Sie die signierten Header hinzu, gefolgt von einem Zeilenumbruchzeichen. Dieser Wert befindet sich in der Liste der Header, die Sie in die kanonischen Header aufgenommen haben. Durch Hinzufügen dieser Headerliste teilen Sie AWS mit, welche Header in der Anforderung Teil des Signaturprozesses sind und welche AWS ignorieren kann (z. B. etwaige zusätzliche Header, die von einem Proxy hinzugefügt wurden), um die Anforderung zu validieren.

    Der host-Header muss als signierter Header eingefügt werden. Wenn Sie ein Datum oder einen x-amz-date-Header verwenden, müssen Sie diesen Header auch der Liste signierter Header hinzufügen.

    Um die Liste signierter Header zu erstellen, wandeln Sie alle Headernamen in Kleinbuchstaben um, sortieren Sie sie nach Zeichencode und verwenden Sie ein Semikolon zur Trennung der Headernamen. Der folgende Pseudocode beschreibt, wie Sie eine Liste signierter Header erstellen. Lowercase ist eine Funktion, die alle Zeichen in Kleinbuchstaben umwandelt.

    SignedHeaders = Lowercase(HeaderName0) + ';' + Lowercase(HeaderName1) + ";" + ... + Lowercase(HeaderNameN)

    Erstellen Sie die Liste signierter Header, indem Sie die Sammlung der Headernamen durcharbeiten, sortiert nach Zeichencode in Kleinbuchstaben. Fügen Sie für jeden Headernamen außer dem letzten ein Semikolon (;) an den Headernamen an, um ihn vom folgenden Headernamen zu trennen.

    Beispiel signierte Header

    content-type;host;x-amz-date\n
  6. Verwenden Sie eine Hash-(Digest-)Funktion wie SHA256 zum Erstellen eines Hash-Werts aus der Nutzlast im Text der HTTP- oder HTTPS-Anforderung. Bei Signature Version 4 müssen Sie keine bestimmte Zeichenkodierung für die Kodierung von Text in der Nutzlast verwenden. Bei einigen AWS-Services ist jedoch möglicherweise eine spezielle Kodierung erforderlich. Weitere Informationen finden Sie in der Dokumentation zu dem jeweiligen Service.

    Beispiel Struktur der Nutzlast

    HashedPayload = Lowercase(HexEncode(Hash(requestPayload)))

    Wenn Sie die zu signierende Zeichenfolge erstellen, geben Sie den Signieralgorithmus an, den Sie für das Hashing der Nutzlast verwendet haben. Wenn Sie beispielsweise SHA256 verwendet haben, geben Sie AWS4-HMAC-SHA256 als Signieralgorithmus an. Die gehashte Nutzlast muss als Hexadezimalwert in Kleinbuchstaben dargestellt werden.

    Wenn die Nutzlast leer ist, verwenden Sie eine leere Zeichenfolge als Eingabe für die Hash-Funktion. Im IAM-Beispiel ist die Nutzlast leer.

    Beispiel gehashte Nutzlast (leere Zeichenfolge)

    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
  7. Um die fertige kanonische Anforderung zu erstellen, verbinden Sie alle Komponenten aus jedem Schritt zu einer einzigen Zeichenfolge. Wie bereits erwähnt endet jede Komponente mit einem Zeilenumbruchzeichen. Wenn Sie dem oben genannten Pseudocodebeispiel für die kanonische Anforderung folgen, sehen Sie das entsprechende Ergebnis im folgenden Beispiel.

    Beispiel kanonische Anforderung

    GET / Action=ListUsers&Version=2010-05-08 content-type:application/x-www-form-urlencoded; charset=utf-8 host:iam.amazonaws.com x-amz-date:20150830T123600Z content-type;host;x-amz-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
  8. Erstellen Sie einen Digest (Hash) der kanonischen Anforderung mit dem gleichen Algorithmus, den Sie für das Hashing der Nutzlast verwendet haben.

    Anmerkung

    Signature Version 4 setzt nicht voraus, dass Sie eine bestimmte Zeichenkodierung für die Kodierung der kanonischen Anforderung verwenden, bevor der Digest berechnet wird. Bei einigen AWS-Services ist jedoch möglicherweise eine spezielle Kodierung erforderlich. Weitere Informationen finden Sie in der Dokumentation zu dem jeweiligen Service.

    Die gehashte kanonische Anforderung muss als Zeichenfolge aus Hexadezimalzeichen in Kleinbuchstaben dargestellt werden. Das folgende Beispiel zeigt das Ergebnis der Verwendung von SHA-256 für das Hashing der kanonischen Beispielanforderung.

    Beispiel gehashte kanonische Anforderung

    f536975d06c0309214f805bb90ccff089219ecd68b2577efef23edd43b7e1a59

    Integrieren Sie die gehashte kanonische Anforderung in die zu signierende Zeichenfolge in Aufgabe 2: Erstellen einer zu signierenden Zeichenfolge für Signature Version 4.