Fine Grained Authorization: Auth0 baut OSS-Autorisierungsarchitektur auf

Foto: ArtemisDiana – shutterstock.com

Das OpenFGA-Projekt von Auth0 ist ein Open-Source-Projekt, das sich zum Ziel gesetzt hat, eine universelle Authentifizierungslösung anzubieten. FGA steht für “Fine Grained Authorization”, ein granularer Ansatz zur Autorisierungsmodellierung.

Authentifizierung vs. Autorisierung

Bei der Authentifizierung geht es um das Wer, bei der Autorisierung um das Was. Das bedeutet Authentifizierung beantwortet die Frage: Wer sind Sie? Autorisierung beantwortet die Frage: Wer sind Sie und was dürfen Sie tun?

Beides sind wesentliche Bereiche der Cybersicherheit. Allerdings stellt die Autorisierung die anspruchsvollere architektonische Herausforderung dar. Das liegt daran, dass die Autorisierung mit mehr Komplexität und weitaus mehr Datenpunkten zu tun hat.

Die Autorisierung muss eine ganze Reihe von Entitäten mit Berechtigungen wie URLs und Geschäftsobjekte sowie Zugriffsarten verfolgen. Darüber hinaus muss sie sich auch mit der Erteilung und dem Entzug von Berechtigungen für diese Objekte befassen. So wird nicht nur geregelt, wer Zugriff auf welche Objekte hat, sondern auch, wer die Berechtigung hat, also die Kontrollhierarchie zwischen Organisationen und Einzelpersonen.

Jeder, der sich schon einmal mit diesen Dingen beschäftigt hat, weiß, wie unübersichtlich das werden kann, gerade beim Nachverfolgen und Anwenden von Berechtigungen. Die Schwierigkeiten vervielfachen sich, je größer und komplexer das System wird. Die einfache Skalierbarkeit kann angesichts von Millionen von Berechtigungsprüfungen für Milliarden von Entitäten zu einer echten Herausforderung werden.

Ein universeller, quelloffener Autorisierungsmechanismus

Der Aufbau eines allgemeinen Systems für solche Anforderungen – das flexibel genug ist, um mit der damit verbundenen Vielfalt, aber dennoch zuverlässig, sicher und leistungsfähig funktioniert – ist ein umfangreiches Unterfangen. Ein solches System birgt jedoch große Vorteile für Unternehmen. Es würde nicht nur die Autorisierung standardisieren, sondern auch die anwendungsübergreifende Authentifizierungskommunikation rationalisieren.

Darüber hinaus kann durch die Konzentration der Autorisierung in einem einzigen, gut getesteten System die Sicherheit verbessert werden.

Das Zansibar-Projekt von Google beschreibt eine solche universelle Autorisierungsschicht. Es beinhaltet eine Reihe von technologischen Ideen, um die Leistungs- und Verfügbarkeitsziele eines solchen Systems zu erreichen. Zudem bietet es eine relativ entwicklerfreundliche Programmierschnittstelle (API) für die Interaktion mit dem System. Beispielsweise kann damit eine universelle domänenspezifische Sprache (DSL) für die Beschreibung von Benutzern, Gruppen, Rollen und Zugriffskontrolllisten (ACLs) für den Ausdruck von Berechtigungen verwendet werden.

Der mittlerweile zu Okta gehörende Anbieter von Identity & Access-Management (IAM-)Lösungen Auth0 will nun auf Basis von Zansibar und seinem Fine-Grained-Authorization-Ansatz eine SaaS-Struktur zur Autorisierung bereitstellen. Diese besteht im Wesentlichen aus einer Remote-API, in die sich jede App integrieren lassen soll, um einen universellen Berechtigungsdienst zu erhalten.

Matias Woloski Gründer und CTO von Auth0 beschreibt es als einen leistungsstarken und flexiblen Autorisierungs-Microservice, den man nicht selbst entwickeln und betreiben muss. Dieses Modell ermögliche es Anwendungsentwicklern, einen Großteil der Komplexität der Autorisierung an den Remote-Service auszulagern, während sie die Kontrolle über die meisten Daten im Haus behalten.

Obwohl dieser Ansatz für viele Anwendungsfälle geeignet scheint, hat der Anbieter einen weiteren Schritt unternommen und seinen FGA-Kern als OpenFGA-Projekt (GitHub Repo) zur Verfügung gestellt. Das soll die Verpflichtung von Auth0 zu Open Source demonstrieren. Außerdem sollen damit Know-how und Fähigkeiten der OSS-Community mit einfließen, was den Ausbau und die Weiterentwicklung fördere.

Woloski erklärt die Strategie von Auth0 wie folgt: “Durch das Open-Source-Modell ermöglichen wir es Entwicklern, die Komponente in ihre eigene Infrastruktur einzubetten. Dabei können sie selbst entscheiden, ob sie es für sich als Service mit zusätzlichen Unternehmensfunktionen nutzen wollen oder ob sie weiterhin die Open-Source-Version verwenden wollen. Wir verpflichten uns, diese langfristig zu pflegen.”

OpenFGA-Server

Das Herzstück des Projekts ist das Berechtigungsmodul selbst, ein eigenständiger Server, der die Berechtigungsanfragen bearbeiten kann. Der OpenFGA-Server ist im Hinblick auf die Datenspeicherung modular aufgebaut. Derzeit kann man zwischen einem In-Memory-Datenspeicher oder einer herkömmlichen PostgresSQL-Datenbank wählen.

Die Möglichkeit, den Server auf einer eigenen Infrastruktur laufen zu lassen, ist Auth0 zufolge ein entscheidender Vorteil, da einige Compliance-Situationen dies erforderten. Bei diesem Server handelt es sich im Wesentlichen um eine HTTP-API, die die Definition von Berechtigungsmodellen und deren Abfrage/Änderung ermöglicht.

Der Server ist in Go geschrieben und lässt sich aus den Quellen selbst erstellen, aber die meisten Endbenutzer werden vermutlich die Binärdateien oder das Docker-Image einsetzen. Eine Schnellstartanleitung für den Betrieb auf localhost über Docker finden Sie hier.

Da der OpenFGA-Server auf der Zanzibar-Architektur basiert, liegt der Fokus auf Skalierbarkeit und Verfügbarkeit. Das hänge jedoch stark von der zugrunde liegenden Infrastruktur ab, sagen die AuthO-Techniker.

“Zanzibar-Implementierungen sind stark darauf optimiert, ob ein Benutzer eine Aktion auf einer Ressource auf skalierbare Weise durchführen kann. OpenFGA ist da keine Ausnahme”, betont Woloski. “Wenn die Auth0 FGA-Implementierung verwendet wird, wird Auth0 die Infrastruktur besitzen und sicherstellen, dass sie hoch skalierbar und verfügbar ist. Die OpenFGA-Nutzer werden für den Betrieb des Dienstes auf ihrer Infrastruktur verantwortlich sein, so dass die Skalierbarkeit undVerfügbarkeitseigenschaften des Dienstes von ihnen abhängen.”

OpenFGA-Klient

Sobald der Server läuft, können Anwender einen Client in ihrer Anwendung einrichten, der auf dem von Ihnen verwendeten Stack basiert – derzeit gibt es Software Development Kits (SDKs) für Node, Go und .NET. Der Client ermöglicht die Interaktion mit der Server-API

Die erste Aufgabe besteht darin, einen Speicher auf dem Server zu definieren, also das Stammobjekt für die Speicherung der Autorisierungsinformationen, ähnlich wie eine Datenbank in einem Datenbankmanagementsystem (DBMS). Der Speicher wird dann mit dem Berechtigungsmodell konfiguriert, ähnlich wie das Schema in einer Datenbank.

Sobald der Server eingerichtet, ein Client installiert und der Speicher bereitgestellt ist, lässt sich das Modell definieren.Das funktioniert per Anfrage im JSON-Format. Zum Beispiel wird mit dem Node-Client ein einfaches Datenmodell wie in Listing 1 konfiguriert (dies stammt aus dem Auth0-Schnellstart).

Tupel

Ein Tupel besteht aus drei Entitäten: einem Benutzer, einer Beziehung und einem Objekt. Sie drücken die Instanzen von Dingen innerhalb des Datenmodells aus. Anwender können ein Tupel im Designer im unteren linken Fensterbereich erstellen. Zum Beispiel: Besitzer: Alice, Beziehung: Leser, Objekt: Dokument:z

Wenn die Beziehung definiert ist, lässt sich eine Abfrage mit dem Query Parser am unteren Rand des Bildschirms durchführen, zum Beispiel: Wer ist mit document:z als Leser verbunden. Alle Beziehungen sind über den Code-Client änderbar.

Dies gibt Anwendern viele Möglichkeiten zur Steuerung der Autorisierung innerhalb ihrer Anwendung, einschließlich der self-referential Gewährung und des Entzugs von Autoritäten auf der Grundlage von Gruppen und Rollen.

Die Dokumentation (die jetzt auch als Open Source verfügbar ist) deckt viele weitere Themen und Anwendungsfälle ab, darunter die Verwendung von openID und die Besonderheiten der Sicherung von Ressourcen wie URLs.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.