Der ultimative Leitfaden zur Einrichtung von Multi-Tenant-Authentifizierung und -Autorisierung

Eine Multi-Tenant-App zu bauen kann herausfordernd sein, mit vielen Aspekten, die es zu beachten gilt. Dieser Artikel fasst alle unsere vorherigen Blogposts zum Verständnis von Multi-Tenant- und Organisationspraktiken zusammen. Für einen schnellen Start und um Zeit zu sparen, schau dir einfach diesen Artikel an, er enthält alles, was du brauchst!

Die allgemeinen Richtlinien sind in den folgenden Schritten skizziert:

1. Verstehe die Multi-Tenant-Architektur
2. Mache eine Zuordnung der Anwendungsfälle deiner Multi-Tenant-App
3. Erreiche Tenant-Isolierung
4. Definiere, wie du die Identitäten verwalten möchtest
5. Wähle die geeigneten Autorisierungsmodelle

Was ist Multi-Tenant-Architektur#

Software-Multi-Tenancy ist eine Software-Architektur, in der eine einzelne Instanz von Software auf einem Server läuft und mehreren Mietern dient. Systeme, die auf diese Weise entworfen wurden, sind "geteilt" (statt "dediziert" oder "isoliert").

Ein Mieter ist eine Gruppe von Benutzern, die gemeinsam auf die spezifische Softwareinstanz mit bestimmten Berechtigungen zugreifen.

Einer der wichtigsten Denkansätze bei der Multi-Tenancy ist "geteilt". In der weiter gefassten Definition von Multi-Tenancy bedeutet es nicht, dass jede Komponente in einer Lösung geteilt ist. Vielmehr bedeutet es, dass zumindest einige Komponenten einer Lösung für mehrere Mieter wiederverwendet werden. Dieses Terminus breit zu verstehen kann dir besser helfen, die Bedürfnisse deiner Kunden zu verstehen und woher sie kommen.

Sobald du die Multi-Tenant-Architektur verstanden hast, besteht der nächste Schritt darin, deine App auf reale Szenarien anzuwenden, wobei der Fokus auf spezifischen Produkt- und Geschäftsanforderungen liegt.

Was sind die Anwendungsfälle für Multi-Tenant-Anwendungen?#

Multi-Tenant in SaaS#

Multi-Tenant-Apps finden oft ihren Platz in Business-to-Business (B2B)-Lösungen wie Produktivitätstools, Kollaborationssoftware und anderen Software-as-a-Service (SaaS)-Produkten. In diesem Kontext stellt jeder "Mieter" typischerweise einen Geschäftskunden dar, der mehrere Benutzer (seine Mitarbeiter) haben kann. Außerdem könnte ein Geschäftskunde mehrere Mieter haben, um unterschiedliche Organisationen oder Geschäftseinheiten darzustellen.

Multi-Tenant in generischen B2B-Anwendungsfällen#

B2B-Anwendungen gehen über SaaS-Produkte hinaus und involvieren oft die Nutzung von Multi-Tenant-Apps. In B2B-Kontexten dienen diese Apps als eine gemeinsame Plattform, die verschiedenen Teams, Geschäftskunden und Partnerunternehmen den Zugang zu deinen Anwendungen ermöglicht.

Betrachte zum Beispiel ein Ride-Sharing-Unternehmen, das sowohl B2C- als auch B2B-Apps bereitstellt. Die B2B-Apps bedienen mehrere Geschäftskunden, und eine Multi-Tenant-Architektur kann bei der Verwaltung ihrer Mitarbeiter und Ressourcen helfen. Um dies zu veranschaulichen: Wenn das Unternehmen ein einheitliches Benutzersystem beibehalten möchte, kann es eine Architektur wie das folgende Beispiel entwerfen:

Sarah hat sowohl eine persönliche als auch eine geschäftliche Identität. Sie nutzt den Ride-Sharing-Service als Passagierin und arbeitet in ihrer Freizeit auch als Fahrerin. In ihrer beruflichen Rolle verwaltet sie auch ihr Geschäft und nutzt diese geschäftliche Identität, um Partnerin mit Geschäft 1 zu sein.

Warum du Multi-Tenancy in SaaS-Produkten einsetzen solltest#

Skalierung mit Multi-Tenancy#

Für Unternehmensgeschäfte ist Multi-Tenancy der Schlüssel, um ihre Anforderungen an Verfügbarkeit, Ressourcenmanagement, Kostenmanagement und Datensicherheit effektiv zu erfüllen. Auf technischer Ebene vereinfacht die Einführung eines Multi-Tenant-Ansatzes deine Entwicklungsprozesse, minimiert technische Herausforderungen und fördert nahtlose Erweiterungen.

Schaffung eines einheitlichen Erlebnisses#

Bei der Untersuchung der Wurzeln von SaaS-Produkten ist es vergleichbar mit einem Gebäude, das verschiedene Apartments beherbergt. Alle Mieter teilen gemeinsame Versorgungsdienstleistungen wie Wasser, Strom und Gas, behalten jedoch die unabhängige Kontrolle über das Management ihres eigenen Raums und ihrer Ressourcen. Dieser Ansatz vereinfacht das Immobilienmanagement.

Sicherheit durch Tenant-Isolierung gewährleisten#

In einer Multi-Tenancy-Architektur wird der Begriff "Mieter" eingeführt, um Grenzen zu schaffen, die die Ressourcen und Daten verschiedener Mieter innerhalb einer gemeinsamen Instanz trennen und sichern. Dies stellt sicher, dass die Daten und Operationen jedes Mieters getrennt und sicher bleiben, auch wenn sie die gleichen zugrunde liegenden Ressourcen nutzen.

Warum du Tenant-Isolierung erreichen solltest#

Wenn du über Multi-Tenant-Anwendungen sprichst, ist es immer notwendig, Tenant-Isolierung zu erreichen. Das bedeutet, die Daten und Ressourcen verschiedener Mieter innerhalb eines gemeinsamen Systems (zum Beispiel einer Cloud-Infrastruktur oder einer Multi-Tenant-Anwendung) getrennt und sicher zu halten. Dies verhindert unbefugte Versuche, auf die Ressourcen eines anderen Mieters zuzugreifen.

Auch wenn die Erklärung abstrakt erscheinen mag, werden wir Beispiele und wichtige Details verwenden, um die Isolierungsmentalität und die Best Practices zur Erreichung der Tenant-Isolierung weiter zu erläutern.

Tenant-Isolierung steht nicht im Widerspruch zum "geteilten" Denkansatz von Multi-Tenancy#

Das liegt daran, dass Tenant-Isolierung nicht unbedingt eine Konzeption auf Infrastrukturressourcenebene ist. Im Bereich von Multi-Tenancy und Isolierung sehen einige Isolation als eine strikte Trennung zwischen tatsächlichen Infrastrukturressourcen. Dies führt üblicherweise zu einem Modell, in dem jeder Mieter separate Datenbanken, Recheninstanzen, Konten oder private Clouds hat. In Szenarien mit gemeinsamen Ressourcen, wie Multi-Tenant-Apps, kann die Art und Weise, Isolation zu erreichen, ein logisches Konstrukt sein.

Tenant-Isolierung konzentriert sich ausschließlich darauf, den Kontext des “Mieters” zu verwenden, um den Zugang zu Ressourcen zu beschränken. Es bewertet den Kontext des aktuellen Mieters und nutzt diesen Kontext, um zu bestimmen, welche Ressourcen für diesen Mieter zugänglich sind.

Authentifizierung und Autorisierung sind nicht gleich "Isolierung"#

Den Zugang zu deinen SaaS-Umgebungen mithilfe von Authentifizierung und Autorisierung zu kontrollieren ist wichtig, aber es reicht nicht aus für eine vollständige Isolierung. Diese Mechanismen sind nur ein Teil des Sicherheitspuzzles.

Die Leute fragen oft, ob man mit allgemeinen Autorisierungslösungen und rollenbasierter Zugriffskontrolle (RBAC) Tenant-Isolierung erreichen kann?

Hier ist das Problem, du kannst eine Multi-Tenant-App bauen, aber du kannst nicht sagen, dass du Tenant-Isolierungsstrategien als Best Practice erreicht und eingesetzt hast. Wir empfehlen es im Allgemeinen nicht, weil

Um dies zu veranschaulichen, betrachte eine Situation, in der du Authentifizierung und Autorisierung für dein SaaS-System eingerichtet hast. Wenn sich Benutzer anmelden, erhalten sie einen Token, der Informationen über ihre Rolle enthält, welche festlegt, was sie in der Anwendung tun können. Dieser Ansatz erhöht die Sicherheit, garantiert jedoch keine Isolierung.

Verwende "Organisation", um den SaaS-Produkt-Mieter darzustellen, um Tenant-Isolierung zu erreichen#

Allein auf Authentifizierung und Autorisierung zu setzen, verhindert nicht, dass ein Benutzer mit der richtigen Rolle auf die Ressourcen eines anderen Mieters zugreift. Daher müssen wir einen "Mieter"-Kontext integrieren, wie zum Beispiel eine Mieter-ID, um den Zugang zu Ressourcen einzuschränken.

Hier kommt die Tenant-Isolierung ins Spiel. Sie verwendet tenant-spezifische Kennungen, um Grenzen zu schaffen, ähnlich wie Wände, Türen und Schlösser, die eine klare Trennung zwischen Mietern gewährleisten.

Identitätsmanagement in Multi-Tenant-Apps#

Wir haben über Tenant-Isolierung gesprochen, aber was ist mit Identitäten? Wie entscheidest du, ob deine Identitäten "isoliert" sein sollten oder nicht?

Es gibt oft Verwirrung rund um das Konzept der "Identitätsisolierung." Es könnte sich auf Situationen beziehen, in denen ein realer Benutzer in allgemeiner Auffassung zwei Identitäten hat.

1. Beide Identitäten können innerhalb eines einzigen Identitätssystems existieren. Zum Beispiel könnte Sarah eine persönliche E-Mail registriert haben, die über Single Sign-On (SSO) mit einer geschäftlichen E-Mail verbunden ist.
2. Benutzer halten zwei unterschiedliche Identitäten innerhalb separater Identitätssysteme, die völlig separate Produkte repräsentieren. Diese Produkte stehen in keinerlei Verbindung zueinander.

Zu Zeiten werden diese Szenarien als "Identitätsisolierung" bezeichnet. Dennoch könnte dieses Label in der Entscheidungsfindung nicht hilfreich sein.

Anstatt zu bestimmen, ob du "Identitätsisolierung" benötigst, bedenke

Diese Antwort kann dein Systemdesign leiten. Für eine kurze Antwort bezüglich einer Multi-Tenant-App,

In Multi-Tenant-Anwendungen werden Identitäten, anders als mieterspezifische Ressourcen und Daten, von mehreren Mietern geteilt. Stell dir vor, du wärst der Verwalter des Gebäudes; du möchtest keine zwei separaten Namenslisten pflegen, um die Identitäten deiner Mieter zu verwalten.

Beim Streben nach Tenant-Isolierung hast du vielleicht den wiederkehrenden Schwerpunkt auf den Begriff "Organisation" beobachtet, der oft als Best Practice für den Aufbau von Multi-Tenant-Anwendungen gilt.

Durch die Verwendung des Konzepts "Organisation" kannst du Tenant-Isolierung in deiner Multi-Tenant-Anwendung erreichen und dabei ein einheitliches Identitätssystem beibehalten.

Wie du das geeignete Autorisierungsmodell auswählst und entwirfst#

Beim Auswählen des richtigen Autorisierungsmodells solltest du diese Fragen in Betracht ziehen:

1. Entwickelst du ein B2C-, B2B- oder eine Kombination aus beiden Produkttypen?
2. Hat deine App eine Multi-Tenant-Architektur?
3. Gibt es einen Bedarf an einem bestimmten Isolationsniveau in deiner App, wie es von der Geschäftseinheit bestimmt wird?
4. Welche Berechtigungen und Rollen müssen im Kontext der Organisation definiert werden und welche nicht?

Welche verschiedenen Autorisierungsmodelle sind in Logto verfügbar?#

Rollenbasierte Zugriffskontrolle#

RBAC (Role-Based Access Control) ist eine Methode zur Gewährung von Benutzerberechtigungen basierend auf ihren Rollen, die eine effektive Verwaltung des Zugriffs auf Ressourcen ermöglicht.

Diese allgemeine Technik liegt der Zugangskontrolle zugrunde und ist ein wesentlicher Bestandteil der Autorisierungsfunktionen von Logto. Als umfassende Identitätsmanagementplattform bietet Logto maßgeschneiderte Lösungen für verschiedene Ebenen und Entitäten, die Entwicklern und Unternehmen bei unterschiedlichen Produktarchitekturen helfen.

API-Rollenbasierte Zugriffskontrolle#

Um allgemeine API-Ressourcen zu schützen, die nicht spezifisch für irgendeine Organisation sind und keine Kontextbeschränkungen benötigen, ist das API-RBAC-Feature ideal.

Einfach die API registrieren und Berechtigungen zu jeder Ressource zuweisen. Danach steuere den Zugang durch die Beziehung zwischen Rollen und Benutzern.

API-Ressourcen, Rollen und Berechtigungen werden hier unter einem einheitlichen Identitätssystem "demokratisiert". Dies ist ziemlich üblich in B2C-Produkten mit weniger Hierarchie und benötigt kein sehr tiefes Isolationsniveau.

Organisationsrollenbasierte Zugriffskontrolle#

In der B2B- und Multi-Tenant-Umgebung ist die Tenant-Isolierung notwendig. Um dies zu erreichen, werden Organisationen als Kontext für die Isolierung verwendet, was bedeutet, dass RBAC nur wirksam ist, wenn ein Benutzer einer spezifischen Organisation angehört.

Organisation RBAC konzentriert sich darauf, den Zugang auf Organisationsebene statt auf API-Ebene zu steuern. Dies bietet erhebliche Flexibilität für die Selbstverwaltung auf Organisationsebene auf lange Sicht, aber dennoch innerhalb eines einheitlichen Identitätssystems.

Ein Hauptmerkmal des Organisation-RBAC ist, dass Rollen und Berechtigungen im Allgemeinen standardmäßig in allen Organisationen gleich sind, was Logtos "Organisationstemplet" äußerst bedeutungsvoll macht, um die Entwicklungseffizienz zu verbessern. Dies stimmt mit der geteilten Philosophie von Multi-Tenant-Apps überein, in denen Zugangskontrollrichtlinien und Identitäten gemeinsame Infrastrukturkomponenten über alle Mieter (App-Mieter) hinweg sind, eine gängige Praxis in SaaS-Produkten.

Abschluss#

Dieser Artikel bietet alles, was du brauchst, um mit der Vorbereitung und Konfiguration von Multi-Tenant-Apps zu beginnen. Probier Logto noch heute aus und beginne mit der Anwendung von Best Practices für die Entwicklung von Multi-Tenant-Apps mit Organisationen.