AWS Lambda und API Gateway, Teil 3 API-Schlüssel zuweisen und testen

Bisher ist unsere mittels Amazon API Gateway auf AWS gehostete Rest-API öffentlich. Jeder, der die Public URL kennt, kann diese aufrufen oder je nach definierter Methode sogar einen Upload veranlassen. Das wollen wir in diesem Workshop ändern.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Um bei AWS gehostete Rest-APIs abzusichern, lässt sich ein entsprechender Key hinterlegen. Dazu gehen wir zuerst in unsere API „in“ der Get-Methode zum Abschnitt „Methodenanforderung“ und setzen im Abschnitt „Einstellungen“ den Eintrag für „API-Schlüssel erforderlich“ auf „True“.

Jetzt wechseln wir in der API-Gateway-Konsole zum Hauptmenü „Schlüssel“ und erstellen mit „Aktionen / API-Schlüssel erstellen“ einen neuen Key. Hierzu vergibt man einen Namen, lässt die Voreinstellung „Automatisch generieren“ bestehen und klickt dann auf „Speichern“. Danach können wir auf „Schlüssel anzeigen“ klicken. Den erstellten Schlüssel müssen wir bei künftigen Anfragen im Anfrage-Header mit übergeben.

Anschließend können wir mit der gleichnamigen Schaltfläche einen so genannten „Nutzungsplan“ hinzufügen. Den haben wir aber noch nicht und wählen daher im Hauptmenü der Konsole das Menü „Nutzungspläne“, in welchem wir einen neuen Plan mit „Erstellen“ anlegen. Der bekommt einen „Namen“, ggf. eine „Drosselung“ und ein „Kontingent“. Wir setzen die Drosselung auf 5 Anforderungen pro Sekunde, ebenso die Burst-Rate (Steigerung), um die Funktionalität später gut testen zu können. Das Kontingent (Quota) setzen wir auf maximal 100 Anforderungen pro Tag.

Danach klicken wir auf „Weiter“ und ordnen unseren „plan1“ die gewünschte API und API-Stufe (Stage) zu. Achtung: In der GUI wird leicht übersehen, dass man erst auf das kleine Häkchen oben rechts klicken muss, bevor „Weiter“ klickbar wird. Jetzt müssen wir noch den API-Key der API zuweisen. Das passiert mit der Schaltfläche „API-Schlüssel zu Nutzungsplan hinzufügen“ im Tab „API-Schlüssel“.

Auch hier ist es wieder erforderlich, auf das kleine Häkchen oben rechts zu klicken. Bevor wir den API-Key testen können, müssen wir die API wieder neu bereitstellen. Wenn wir nun einen Zugriff ohne Schlüssel versuchen, bekommen wir wie erwartet die Antwort „Forbidden“.

APIs testen mit Postman

Für das Testen des API-Keys verwenden wir der Bequemlichkeit halber (und weil das Testen von APis mit dem im Folgenden vorgestellten Tool automatisierbar ist) ein passenden API-Test-Tool wie z. B. das Tool „Postman“, welches in der Standard-Version mit Community-Support kostenfrei ist.

Postman ist unter Entwicklern sehr populär und lässt sich z. B. in der Windows-Version von der Postman-Projektseite herunterladen. Die freie Version eignet sich für Einzelpersonen und kleine Teams. Die Version Postman Pro unterstützt bis zu 50 User im Team und kostet 8 US-Dollar per User und Monat, während Postman Enterprise mit 18 Dollar pro User und Monat für beliebig große Teams kostet. Das Installieren der Windows-Version ist selbsterklärend.

Wurde Postman erfolgreich installiert und gestartet, definiert man einfach einen neuen Request wie z. B. „Test-HelloAPI“, wählt dann bei der HTTP-Methode „Get“ und trägt bei „Enter request URL“ unsere API-Gateway-URL ein. Nun wechseln wir zum Tab „Authorization“, lassen den Typ auf „Inherit auth from parents“ und senden den Request erst einmal mit „Send“ ab. Wir bekommen dann zunächst genau die gleiche „Forbidden“-Antwort, wie aus der AWS Console.

Um den API-Key mit zu übergeben, müssen wir jetzt einen „Header“ hinzufügen. Hierzu wechseln wir zum Abschnitt „Headers“ und tragen in der Key-Spalte „x-api-key“ mit dem Value unseres API-Keys ein. Damit sollte auch der Aufruf einer per API-Key geschützten API funktionieren. Danach kann man theoretisch noch das Kontingent und die Drosselung testen.

(ID:45899509)