Das neue AAA: APIs, Authentifizierung und Verfügbarkeit

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Ihr habt es euch vielleicht schon gedacht: Ja, ich gehöre zu diesen Leuten, die Pokémon Go spielen. Oder, wie es in letzter Zeit oft der Fall ist, Pokémon Go nicht spielen. Das ist schlecht, denn es bedeutet auch, dass unser jüngstes Kind nicht spielt. Wie sich herausgestellt hat, verwenden wir nämlich beide Pokémon-Trainer-Club-Konten (PTC) statt Google-Konten und können uns nicht anmelden.

Das ist insofern von Bedeutung, als wir beide frustriert darüber sind, dass wir uns nicht „authentifizieren“ und zum Spielen anmelden können, während mein Mann sich für sein Google-Konto entschieden hat und, nun ja, nicht dieselben Probleme hat.

Das brachte mich dazu, einigen technischen Fragen nachzugehen, die wirklich jedes Unternehmen beschäftigen sollten – unabhängig davon, welche App es auf den Markt bringt. Dabei geht es um das neue AAA: APIs, Authentifizierung und Verfügbarkeit.

Interessanterweise begann diese Suche, als ich in Forbes einen Artikel über das Aufspüren von Pokémon las in Pokémon Go. Ja, Forbes. So groß ist das Thema. Jedenfalls führte das zu einem weiteren Artikel und dann noch einem, wobei in einem davon vermutet wurde, dass das Tracking (zumindest anfangs) deshalb nicht funktionierte, weil bei einem Spiel-Update versehentlich ein API-Schlüssel in den Tracking-Aufrufen an die Server von Niantic weggelassen worden war.

Ob das nun der Fall ist oder nicht – ein solcher Fauxpas würde APIs tatsächlich lahmlegen. Doch ich fragte mich immer wieder: Wenn ich mich nicht bei meinem PTC-Konto anmelden und spielen konnte, warum konnte ich dann zu meinem Google-Konto wechseln und ganz einfach und problemlos loslegen?

Der Zusammenhang zwischen API und Authentifizierung

Nun, das brachte mich dazu, auf github herumzustöbern und Pokémon-Go-APIs zu durchforsten (ich bevorzuge Java, aber Python gibt es auch – tobt euch aus), und da ging mir endlich ein Licht auf. Denn so gut wie jeder API-Aufruf in diesen Repositorys behandelt dieselbe Ausnahme: LoginFailedException.

Mit anderen Worten: Selbst ein einfacher Aufruf zur Suche nach Pokémon in der Nähe kann zu einer LoginFailedException führen.

Was eigentlich gar nicht so überraschend ist. Denn monolithische Webanwendungen verwalten authentifizierte Benutzer häufig mithilfe von Sitzungen, was oft ein Cookie bedeutet, das eine Sitzungs-ID oder ein anderes Token enthält, das die Anwendung überprüft, bevor sie überhaupt etwas anderes tut (für alle, die mitdenken: Das ist eine zustandsbehaftete Architektur). APIs unterscheiden sich darin nicht wesentlich, denn jeder API-Aufruf muss auf irgendeine Weise sicherstellen, dass die aufrufende Anwendung (der Benutzer) überhaupt berechtigt ist, den Aufruf durchzuführen. Sie muss „angemeldet“ sein.

Heutzutage verwenden APIs hierfür häufig API-Schlüssel. Der Schlüssel wird in der Regel mit einem Benutzerprofil abgeglichen, um sicherzustellen, dass der Aufruf autorisiert ist. Und zwar bei jedem Aufruf (in einer zustandslosen Architektur). Für eine solche Entscheidung gibt es verschiedene Gründe, darunter die Möglichkeit, die Aufrufrate zu begrenzen. Und das ist von großer Bedeutung. Im Bericht Apigee’s State of APIs 2016 wurde festgestellt, dass 68 % der APIs ein Quotenmanagement nutzten (auch bekannt als Ratenbegrenzung, Verbrauchsmessung usw.). Um diesen technischen Kniff umzusetzen, muss man zunächst wissen, wie viele Aufrufe in der vergangenen Minute/Stunde/am vergangenen Tag erfolgt sind. Daher müssen diese Daten an einem sicheren Ort erfasst werden, damit Benutzer sie nicht manipulieren und die Anwendung dazu bringen können, mehr Aufrufe pro Zeitraum zuzulassen.

Mit anderen Worten: APIs können die Authentifizierungsinfrastruktur stark belasten, da sie den Status und die Autorisierung überprüfen und gegebenenfalls eine Ratenbegrenzung anwenden müssen. Das ist eine Menge Arbeit.

Doch unsere häufig noch immer traditionellen Denkweisen in Bezug auf App-Architekturen berücksichtigen nicht, wie sich diese zusätzlichen Aufrufe auf die Kapazität auswirken. Diese zusätzlichen Aufrufe zur Verifizierung und Autorisierung werden die Authentifizierungsinfrastruktur erheblich belasten – selbst wenn sie nur regelmäßig erfolgen, um eine Sitzung zu „aktualisieren“. Und zwar dieselbe Authentifizierungsinfrastruktur, die auch die Anmeldung unterstützt. Eine vergleichbare Belastung konnten wir beobachten, als die Browserbeschränkung für Verbindungen pro Benutzer von 2 auf 8 erhöht wurde. Plötzlich beanspruchte ein einzelner Benutzer für den Zugriff auf eine Anwendung achtmal so viele Ressourcen. Ähnlich muss man bei der Ermittlung des Kapazitätsbedarfs einer App, die bei jedem API-Aufruf eine Autorisierung erfordert, nachrechnen und herausfinden, um welchen Faktor der Ressourcenverbrauch eines einzelnen Benutzers steigt.

Andernfalls gibt es nun ja, wütende Achtjährige (und übrigens auch eine wütende Lori), wenn überlastete Anmeldedienste zwischen ihnen und dem Pikachu stehen, das sie unbedingt fangen wollen.

Skalierung von ID und A entscheidend für die Verfügbarkeit

Identitäts- und Zugriffsverwaltung gehören zu den kritischen Anwendungsdiensten. In den vergangenen zwei Jahren haben wir in unseren Umfragen zum Stand der Anwendungsbereitstellung festgestellt, dass ihre Bedeutung zunimmt. Ohne zu viel vorwegzunehmen, zeichnet sich in unseren Daten für 2017 bereits ein Anstieg sowohl bei der Identitätsföderation als auch bei der Anwendungszugriffskontrolle ab. Und das liegt nicht nur an den Anwendungen, sondern auch an den Dingen und an der wachsenden Notwendigkeit, die gesamte Bandbreite der Infrastruktur für Identitätsdienste zu skalieren, um mehr Dinge, mehr Benutzer und mehr Anwendungen zu unterstützen, die über APIs mit Backend-Anwendungen interagieren.

Verfügbarkeit wird häufig ausschließlich anhand der Ausfallzeit bemessen. Wenn die Server in Betrieb waren und ordnungsgemäß funktionierten, galten sie als verfügbar. Das ist eine Betrachtung von innen nach außen. Doch wie bei der Sicherheit müssen wir diese Betrachtungsweise umkehren und die Verfügbarkeit von außen nach innen beurteilen. Auch die Kapazität zählt, und lediglich „in Betrieb“ und „verfügbar“ zu sein, reicht nicht aus. Dienste müssen für alle, die sie nutzen möchten, „in Betrieb“ und „verfügbar“ sein. Das bedeutet, dass sie so schnell skalieren müssen, wie Ihre Python-Skripte ausgeführt werden können.

Das bedeutet auch, die Zusammenhänge zwischen den verschiedenen Backend-Diensten zu verstehen, die die über Ihre APIs bereitgestellten Funktionen tatsächlich umsetzen. Identitäts- und Zugriffsdienste sind für die Verfügbarkeit ebenso entscheidend wie die eigentliche Anwendung selbst. Wie bei der Sicherheit ist auch die Verfügbarkeit nur so gut wie ihr schwächstes Glied. Und wenn Ihre Identitätsdienste nicht ebenso skalierbar sind wie der Rest Ihrer Anwendung – oder sogar noch skalierbarer, falls Ihr Modell eine Authentifizierung bei jedem API-Aufruf vorsieht –, werden Sie feststellen, dass die Verfügbarkeit ein erhebliches Problem darstellt, selbst wenn all Ihre internen Dashboards „grün“ anzeigen.

Denn von außen sehen wir „Rot“ – im wörtlichen wie im übertragenen Sinne.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie