PART II: Mastering
Amazon API Gateway:
Ressourcen und Einstellungen

In diesem zweiten Blog der Reihe über den Amazon API-Gateway, werde ich die verschiedenen Zugriffs- und Einstellungsmöglichkeiten erklären. Welche Möglichkeiten gibt es um eine API bzw. Ressource abzusichern? Wie können Parameter transferiert werden? Dies und noch weitere nützliche Details erfahrt ihr in diesem Blogeintrag.

Autorisierung

Amazon bietet 2 Methoden zur Absicherung der API: IAM und Schlüssel. Diese werden im folgenden genauer Erläutert.

Amazon Identity and Access Management

Um die API vor unautorisierten Zugriff zu schützen, bietet Amazon die Möglichkeit den aufrufenden Benutzer mittels AWS_IAM (Amazon Identity and Access Management) zu autorisieren. Dazu muss man in den Einstellungen der gewünschten Ressource unter „Method Request“ beim Punkt Authorization den Wert „AWS_IAM“ eintragen. Dadurch kann die Ressource nur von gültigen Amazon Benutzern, welche noch dazu die Berechtigung für den Aufruf besitzen, aufgerufen werden. Dadurch erhält man große Flexibilität, man kann die Benutzer über das Amazon Dashboard verwalten, und genau definieren welche Ressourcen wer aufrufen darf.

 Um einen solchen Benutzer zu erstellen, gehen Sie wie folgt vor:

  • Zu „IAM“ im AWS Panel wechseln
  • Untermenüpunkt „Users“ wählen
  • „Create New Users“ drücken
  • Username eingeben
  • Die generierten Credentials (Access Key ID und Secret Access Key herunterladen und speichern)

Berechtigung Zuweisen

Nun muss dem soeben erstelltem Benutzer noch die entsprechenden Berechtigungen zugewiesen werden:

  • Benutzer“ auswählen
  • Zum Reiter „Permissions“ wächseln
  • Den Reiter „Incline Policies“ öffnen
  • Create User Policy“ drücken
  • Custom Policy“ auswählen
  • Policy Name“ eingeben (zBsp. Invoke_Person)
  • Unter Policy Dokument folgendes angeben:
{  "Version": "2012-10-17"  "Statement": [    {      "Sid": "Stmt1455537795000",      "Effect": "Allow",      "Action": [        "execute-api:invoke"      ],      "Resource": [        "arn:aws:execute-api:eu-west-1:885578211264:lmyybeyw04/*/GET/Person"      ]    }  ]}

Der Wert unter Action („execute-api:invoke“) bedeutet, dass der Benutzer die angegebene Ressource aufrufen darf. Und mittels „Ressource“ wird die angegebene Ressource definiert, welche aufgerufen werden darf (Den ARN wird bei „Method-Request“ in der Übersicht der Ressource angezeigt). Es können auch Wildcards mittels ‚*‘ vergeben werden. Achtung: Sie müssen auch immer die OPTIONS-Ressource für den Benutzer freischalten.

Sollten Sie die Fehlermeldung XMLHttpRequest cannot load XXXXX.execute-api.eu-west-1.amazonaws.com/Person. Request header field x-amz-security-token is not allowed by Access-Control-Allow-Headers in preflight response.” erhalten, müssen Sie noch den richtigen Header dafür setzen. Dazu wechseln Sie zur relevanten Option-Ressource im Amazon API Gateway, und wählen Integration Response. Unter Header Mappings tragen Sie beim Header „Access-Control-Allow-Origin“ den Value „‘Content-Type,x-amz-security-token,X-Amz-Date,Authorization,X-Api-Key‘“ ein.

PART II: Mastering Amazon API Gateway: Ressourcen und Einstellungen

Auf der Seite des Client’s wird nun bei jedem Aufruf ein sogenannter hmac aus den Benutzerdaten (Access-Key, Secret-Key) berechnet, und mit dem Request mitgesendet. Näheres zu diesem Verfahren finden Sie hier bzw. hier. Genaueres zum API-Aufruf kommt in einem weiteren Beitrag.

API-Key

Eine weitere Möglichkeit seine API vor unerlaubten Zugriff zu schützen, ist mittels eines API-Keys. Dieser API-Key wird in einem Feld im Header mitgesendet. Ist dieser Schlüssel gültig, wird der Aufruf weitergeleitet, ansonsten blockiert. Um dieses Verfahren zu wählen, müssen Sie unter „Method Execution“ bei „API Key required“ den Wert auf „true“ setzen. API-Keys können über das Menü „API Keys“ in Dashboard beim „Amazon API Gateway“ erzeugt werden. Dieses Vorgehen ist empfohlen, wenn die API zwar geschützt werden soll, aber keine Unterscheidung zwischen den Zugriffsrechten der Benutzer gemacht werden muss. Auch eine Kombination aus beiden Varianten (API-Key und AWS_IAM) ist möglich. 

Einstellungen

Die Einstellungsmöglichkeiten der Ressourcen gliedern sich in 4 getrennte Bereiche. Jeder dieser Bereiche hat seine eigenen Einstellungen, welche im Folgenden genau erklärt werden.

PART II: Mastering Amazon API Gateway: Ressourcen und Einstellungen

Method Request

Hier werden die Einstellungen zum Eingang der Ressource vorgenommen. Neben den bereits vorgestellten Einstellungen zur Autorisation, können hier auch noch Parameter und Headers definiert werden:

  • URL Query String Parameters: Hier werden Parameter definiert, welche über die URL übergeben werden (zBsp. XXXXX.execute-api.eu-west-1.amazonaws.com/Person.
  • HTTP Request Headers: Hier können zusätzliche Header definiert werden, welche beim Aufruf angegeben werden müssen.
  • Request Models: Hier können Models definiert werden, welche im body übertragen werden. Dadurch wird bereits beim Aufruf die Struktur des Models überprüft. Über die genaue Funktionalität von Models erfahren Sie mehr, in einem späteren Blogbeitrag dieser Serie.

Integration Request

Hier werden Einstellungen zum Aufruf definiert. Diese Blogreihe bezieht sich nur auf die Verwendung des API-Gateways mittels Lambda Funktionen, daher wird an dieser Stelle nicht auf die weitere Möglichkeiten (HTTP Proxy, Mock Integration und AWS Service Prody) eingegangen. Folgende Einstellungsmöglichkeiten können hier vorgenommen werden:

  • Integration type: Definition der Art des Aufrufs – wählen Sie hier Lambda Function.
  • Lambda Region: Region in welcher sich die Lambda Funktion befindet.
  • Lambda Function: Name der Lambda Funktion. Der Dialog nach Eingabe und Bestätigung der Funktion, weist darauf hin, dass der API Gateway die Berechtigung bekommt, die Funktion aufzurufen.
  • Invoke with caller credentials: Definiert ob der Aufruf mittels des IAM-Benutzers, welcher die API aufruft gemacht wird (nur bei Autorisation mittels AWS_IAM). Ansonsten wird die Funktion von einem Standard Amazon Benutzer aufgerufen. Empfohlen wird dies zu deaktivieren, da es keine unmittelbare Auswirkung hat.
  • Credentails cache: Hier wird definiert ob die Benutzerdaten auch gecached werden sollen (nur Verfügbar bei Autorisation mit AWS_IAM). Folgende Auswahlmöglichkeiten gibt es:
    • Add callers’s account ID to cache key: Fügt nur die Account-Id zum Cache hinzu.
    • Add callers’s principal to the cache key: Fügt die gesamten Benutzerdaten zum Cache hinzu.
    • Do not add caller credentials to cache key: Cached keine Benutzerdaten.
  • Mapping Tempalte: Hier kann ein Template definiert werden für den Eingangs-Body des Requests. Nützlich um zum Beispiel hier bereits Transformationen vorzunehmen. Mit dem Template:
#set($inputRoot=$input.path('$')){  "user": "$context.identity.userArn"}

Kann zum Beispiel der Amazon-Arn des Benutzers an die Lambda Funktion weitergeleitet werden.

Integration Response

Hier werden Einstellungen zur Rückgabe des Ergebnisses vorgenommen.

  • Lambda Error Regex: Angeben einer Regex nach welcher der Rückgabewert durchsucht wird (zBsp. „400.*“). Wenn diese Regex matched, wird diese Regel angewendet.
  • Method Response Status: Der HTTP-Status, der zurückgeliefert wird.
  • Output Model: Ein bestimmtes Model/Aufbau des Rückgabe-Objektes.
  • Default Mapping: Gibt an, ob dies die Standard-Regel ist.
  • Header Mappings: Die Werte für den Rückgabe-Header setzen.

Method Response

Hier werden die Rückgabe-Stadien definiert.

  • HTTP-Status: Angabe des Status-Codes.
  • Response-Headers: Angabe von Headern für die Antwort.
  • Response-Models: Angabe eines Models/Aufbau des Rückgabe-Objektes

Wie geht’s weiter?

Das erwartet Euch in den weiteren Artikeln dieser Blogreihe:

Wir entwickeln digitale Lösungen mit Leidenschaft

Warum wir das tun? Weil die Verwirklichung Ihrer Vision unser größter Anspruch und die schönste Anerkennung ist. Deshalb nehmen wir uns gerne ausreichend Zeit für die Realisierung Ihres digitalen Projekts.

Kontaktieren Sie uns, wir sind gerne für Ihre Fragen da:

Passend zu diesem Thema:

Interkulturelles Webdesign

Interkulturelles Webdesign

Abhängig davon in welcher Kultur wir leben und wie wir aufwachsen (Erziehung, Familie, Freunde), werden Wahrnehmung und Vorlieben beeinflusst. Auch da…

TYPO3 Chatbot

TYPO3 Chatbot

Chatbots ermöglichen es, die Betreuung von Website-Besuchern im Kundenservice einfach und effizient zu gestalten. Der Einsatz dieser virtuellen Helfer…

Das war das TYPO3camp München 2019

Das war das TYPO3camp München 2019

Vom 13. – 15. September fand das TYPO3camp 2019 in München statt und auch varioous war vor Ort um sich mit anderen TYPO3-Entwicklern und Unternehmen z…