, ,

API-Entwicklung – Service as a Service

API-Entwicklung – Service as a Service

 

In Zeiten von DevOps, hoher Automatisierung und entkoppelter Microservices brauchen wir gut gepflegte Schnittstellen, die nicht nur heute funktionieren, sondern auch in einer skalierenden Welt mit flexibler Roadmap. Wann immer ein neuer Service entsteht, wird auch eine API bereitgestellt.

APIs sind die neuen Produkte

In der Ära der Cloud – und im Speziellen von SaaS-Produkten – wird die Entwicklung und Bereitstellung von APIs immer relevanter: APIs sind die neuen Produkte, denn nicht für jeden Service brauchen wir eine App oder eine Webseite.

Die Entwicklung von APIs

Wer nun selbst eine API bzw. einen Service anbieten will, steht vor einigen Herausforderungen. Die üblichen Schwierigkeiten, die Services schon innerhalb von Projekten verursachen, werden noch einmal verstärkt, da Endkunden damit lange arbeiten sollen. Sie müssen sowohl vernünftig gepflegt und dokumentiert sein, als auch gegen unerlaubte Zugriffe geschützt, veröffentlicht, weiterentwickelt und auch abgerechnet werden können.

Es ist ratsam, seinen Service mit bestehenden Services anzureichern („Services as a Service“) und so die Trennung von Fachlichkeit und Organisation zu erreichen. In unserem konkreten Fall soll der Service nur seine (fachliche) Aufgabe erfüllen und das möglichst gut. Dabei wollen wir uns nicht mit Userverwaltung, dem Generieren von Subscription-Keys oder dem Bau eines Gateways beschäftigen. Dazu kombiniere ich zwei Microsoft Produkte: das Azure API Management als Plattform zur Veröffentlichung meiner APIs sowie das Azure Active Directory B2C zur Verwaltung der API-Nutzer.

Azure Active Directory B2C (Azure AD B2C)

Das Azure Active Directory B2C ist ein cloudbasiertes full-managed System und dient dem Identitäts- und Zugriffsmanagement für Endkunden – in unserem Fall Customer unserer API. Die Idee dahinter ist, dass die Endkunden eines Produktes bzw. einer SaaS-Lösung sich selbst verwalten können und getrennt vom firmeneigenen Active Directory gepflegt werden.

Das Azure AD B2C unterstützt deshalb verschiedene Identitätsprovider aus sozialen Netzwerken – wie bspw. Facebook, Google, Microsoft, Amazon und Twitter – aber auch die Registrierung mit einer eigenen Mailadresse. Es können auch manuell neue User angelegt oder eine Verbindung zum firmeneigenen Active Directory hergestellt werden.

Der Administrator des Azure AD B2C entscheidet, ob die Endnutzer anpassbare Seiten für Sign-Up, Sign-In oder auch Profile-Edit verwenden können.

Authentifizierung/Autorisierung

Über das Azure AD B2C können nun diverse Token zur Autorisierung generiert werden. Die Token werden bei den Web-Requests als JSON Web Token (Bearer) mitgeliefert und die Anwendung überprüft dessen Gültigkeit. Dazu bieten das .NET Framework sowie andere Anbieter diverse Bibliotheken. Bei .NET Core wird dazu direkt die Extension AddAzureAdB2CBearer ausgeliefert und hinzugefügt. Sie nimmt den Kontakt mit dem Azure AD B2C auf und prüft die Gültigkeit der Tokens. Mehr als die Annotation [Authorize] über die Klasse oder Funktion braucht es damit nicht.

Eine Authentifizierung kann aber auch komplexer ausfallen. Anstatt eines Access-Token kann auch ein ID-Token generiert werden, das den konkreten User repräsentiert oder es werden eigene Claims in die Token aufgenommen, die bei der Prüfung herangezogen werden.

Wer darf was?

Mit der Authentifizierung ist es i.d.R. noch nicht getan: Welcher Nutzer darf welche API-Teile aufrufen? Wie viele Aufrufe gestatten ich? Oder strebe ich vielleicht eine nutzungsbasierte Abrechnung an? All das müsste ich entwickeln. Einfacher ist es, ich tue es nicht. Ich spare mir den Code zur Autorisierung und nutze fertige Dienste zum Absichern meiner API und zum Protokollieren der Zugriffe. Das ist der Augenblick wo das API-Management die Bühne betritt…

API-Management (APIM)

Das Azure API Management dient der Veröffentlichung von APIs, die durch interne oder externe Entwickler eingesetzt werden sollen. Es bietet noch einige weitere Funktionen wie Konfiguration und Schutz der API sowie die Analyse des Nutzungsverhaltens. Das APIM besteht aus drei Komponenten – einem Gateway und zwei Portalen.

Als Einstiegspunkt für jeden Entwickler dient das Gateway. Alle Anfragen der APIs durchwandern dieses, werden dort geprüft und protokolliert. Das Gateway kontrolliert die genehmigten Nutzungskontingente, Token oder transformiert Aufrufe entsprechend konfigurierter Policies.

Das Publisher-Portal – auch Admin-Portal genannt – stellt eine Verwaltungsoberfläche für das APIM bereit. Über dieses Portal werden die APIs importiert und geändert. Die Konfiguration der API, die Zugriffe und die Datenflüsse durch das Gateway zum Backend werden ebenfalls hier angepasst. Weiterhin werden hier die Nutzer für das Entwickler-Portal und die Konfiguration der buchbaren Produktpakete festgelegt.

Das Entwickler-Portal gleicht einer Webpräsenz der API für die Entwickler, die das Interface schlussendlich verwenden. Ähnlich wie bei Swagger werden auch hier die einzelnen Funktionen und ihre Antworttypen aufgelistet. Darüber hinaus sind direkte Testaufrufe mit vorkonfigurierten oder generierten Parametern möglich – jedoch nur für abonnierte APIs und stets mit Zugriffsprüfung. Weiterhin können Firmen über das Entwickler-Portal ihre angebotenen APIs mit Hilfe von Blogs, Issue-Management, klassischem CMS und grafischen Anpassungen präsentieren.

Arvato, IT, Cloud, API Architektur

API Verwaltung

Um neue APIs hinzuzufügen, kann von scratch begonnen oder eine bestehende API (via WSDL, JSON, …) importiert werden. Für jede Station des Nachrichtenflusses (Frontend, Inbound, Backend, Outbound) kann anschließend über Policies die Arbeitsweise beeinflusst werden.

Die angelegten APIs können auch nach der Veröffentlichung weiterentwickelt werden, ohne die Endnutzer zu beeinflussen. Dazu wird einfach eine neue Version oder Revision erzeugt und zu einem völlig neuen Backend geroutet oder andere Einstellungen wie Authentifizierung oder Parameter angepasst.

Produkte und Subscriptions

Vor der Veröffentlichung werden einzelne Funktionen der APIs zu Produkten kombiniert. Über das Developer-Portal kann sich ein Endnutzer registrieren, einen Überblick über die APIs verschaffen und sich für verschiedene Produkte subscriben. Dadurch generiert das APIM Keys für den Nutzer, die er beim Aufruf der API übermitteln muss. Das Gateway prüft diese Keys und protokolliert die Aufrufe. Der Betreiber des APIM kann entscheiden, welche Subscriptions er zulässt oder wann diese wieder auslaufen.

Policies

Policies sind Konfigurationen, die durch das API-Gateway bei der Abarbeitung von Requests umgesetzt werden. Sie sind ein sehr mächtiges Werkzeug: Ihr Umfang reicht vom einfachen Anpassungen wie dem Ersetzen von Header-Werten über ein starkes Regelwerk wie eine Aufrufbegrenzung von z.B. nur 100 pro Minute bis hin zu eigenem C#-Code und REST-Aufrufen, die bspw. einen Team-Channel bei 500er-Fehlern benachrichtigt.

Nutzermanagement

Das APIM kann selbst Nutzer verwalten. Viel geschickter ist es aber, das AAD B2C hierzu verwenden. Dadurch können sich neue Entwickler im Developer-Portal registrieren und werden zur Sign-Up Page des AAD B2C weitergeleitet. Ebenso erfolgt der Login über die Seiten des Azure AD B2C.

Möchte ich dann doch einen Token für meine API verlangen, kann die implizite Authentifizierung genutzt werden, wodurch das APIM einen Token für den eingeloggten Nutzer anfordert und ihn an die API weiterleitet. Das Gateway speichert außerdem alle Nutzeraufrufe mit. So kann ich Reports generieren oder Power-BI nutzen, um die Verwendung meiner API zu überwachen oder herauszufinden, welcher Nutzer zu welchem Zeitpunkt welche Funktion aufgerufen hat.

Backend-Schutz

Durch den Subscription-Mechanismus ist meine API geschützt. Das Gateway kümmert sich um die Absicherung und lässt nur Aufrufe durch, die einen validen Subscription-Key mitliefern. Um das Backend noch vor direkten Aufrufen zu schützen, können bspw. IP-Filter in Azure konfiguriert werden. Dadurch sind nur Aufrufe vom Gateway zulässig und der Quellcode bleibt frei von Sicherheitsprüfungen.

Service as a Service

Unser Service selbst benötigt keine Authentifizierung oder andere Schutzmechanismen mehr, muss sich nicht selbst um das Bereitstellen verschiedener Versionen kümmern und muss auch nicht mitloggen, welcher Nutzer ihn aufgerufen hat. Das bereitgestellte Entwickler-Portal dient als Veröffentlichungsplattform unserer API-Produkte. Das Portfolio kann wachsen, gepflegt und mit dem Feedback der Endnutzer weiterentwickelt werden.

Es war noch nie so einfach und noch nie so wichtig wie heute, eine API als Produkt zu veröffentlichen. Unser Service kann einfach seinen Dienst zur Verfügung stellen, alle anderen Features holen wir uns dazu. Eben doch irgendwie Service as a Service.

Beispielcode zur Authentifizierung mit ID-Token gegen AAD B2C: https://github.com/ArvatoSystems/CoreApiVersioningAADB2CAuth


Über den Autor des Beitrags:

Thomas Zühlke

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.