Logtos Multi-Tenancy-Modell erklärt

Die Verwirrung#

Du hast vielleicht schon von einigen Produkten gehört, die den Begriff "Multi-Tenancy" verwenden, um die Identitätsisolierung darzustellen: Jeder Mandant hat seinen eigenen Satz von Benutzern, Rollen, Berechtigungen und Daten.

Es mag kontraintuitiv erscheinen, aber tatsächlich bedeutet "Multi-Tenancy" das Gegenteil: Mehrere Mandanten teilen sich Ressourcen in einer einzigen Instanz. Für Benutzer ist eine Identität in einer App wie ein Führerschein. Zum Beispiel kannst du mit einem Führerschein in verschiedenen Bundesstaaten fahren (eine Identität für mehrere Organisationen), anstatt für jeden Staat einen neuen Führerschein zu beantragen.

Logtos Modell#

Bei Logto erkannten wir dieses Missverständnis bereits zu Beginn unseres Designs und drängten darauf, es für deine Apps und Benutzer richtig zu machen. Hier ist unser Design:

• Ein Mandant kann als eine einzelne Logto-Instanz behandelt werden, die ihren eigenen Satz von Benutzern, Berechtigungen und Daten hat.
• Innerhalb eines Mandanten können mehrere Organisationen existieren. Ein Benutzer kann Mitglied mehrerer Organisationen sein.
• Für jede Organisation folgt das Modell dem rollenbasierten Zugriffssteuerungsmuster (RBAC) und verwendet denselben Satz von Organisationsrollen und Organisationsberechtigungen. Dieser Satz wird als Organisationstemplate bezeichnet.
• Die Organisationsrollen und Organisationsberechtigungen sind nur im Kontext einer Organisation wirksam.
  • Zum Beispiel kann ein Benutzer in einer Organisation ein "Administrator" (Rolle) und in einer anderen Organisation ein "Mitglied" (Rolle) sein.
  • Ohne den Kontext einer Organisation sind Organisationsrollen und Organisationsberechtigungen bedeutungslos.
• Verwende Organisationsberechtigungen, um den Zugriff in einer Organisation zu steuern, anstatt Organisationsrollen zu verwenden.

Dieses Modell bietet Flexibilität und Wiederverwendbarkeit bei der Verwaltung von Identitäten, insbesondere für SaaS-Apps. Wenn wir uns einige beliebte SaaS-Apps ansehen, stellen wir fest, dass sie alle in dieses Modell passen. Der Begriff "Organisation" kann in verschiedenen Apps unterschiedlich sein, wie "Arbeitsbereich", "Team" usw. Aber das Konzept ist dasselbe.

Zum Beispiel in Notion (ein beliebtes Kollaborationstool):

• Du kannst mit einem Konto mehrere Arbeitsbereiche erstellen und beitreten, anstatt dich für jeden Arbeitsbereich mit unterschiedlichen Konten anzumelden.
• Für jeden Arbeitsbereich definiert Notion einen einheitlichen Satz von Zugriffsebenen: "Eigentümer des Arbeitsbereichs" und "Mitglied", während du möglicherweise unterschiedliche Zugriffsebenen für verschiedene Arbeitsbereiche erwartest.

Daher können Benutzer problemlos zwischen Arbeitsbereichen wechseln, ohne sich neu anzumelden oder die Konten zu wechseln, und es bleibt die Isolierung zwischen den Arbeitsbereichen erhalten. Wenn man dies auf Logtos Modell überträgt, bedeutet dies:

• Das Organisationstemplate definiert zwei Rollen: "Eigentümer" und "Mitglied".
• Wenn ein Benutzer einem Arbeitsbereich beigetreten ist, bedeutet dies, dass der Benutzer Mitglied einer Organisation ist und die Rolle "Mitglied" in der Organisation hat.
• Wenn ein Benutzer einen Arbeitsbereich erstellt hat, bedeutet dies, dass der Benutzer Mitglied einer Organisation ist und die Rolle "Eigentümer" in der Organisation hat.

Entsprechend den verschiedenen Rollen kann ein Benutzer unterschiedliche Berechtigungen in verschiedenen Arbeitsbereichen (Organisationen) haben.

Die Vorteile#

Benutzererfahrung#

Für Benutzer bietet dieses Modell ein echtes Single-Sign-On-Erlebnis. Das Wechseln zwischen Organisationen ist so einfach wie das Wechseln zwischen Tabs.

Wiederverwendbarkeit#

Ein Vorteil von SaaS-Apps ist, dass sie standardisiert und skalierbar sind. Zum Beispiel kannst du in Notion mit wenigen Klicks einen neuen Arbeitsbereich erstellen, und er ist sofort einsatzbereit.

Wenn deine App wächst, möchtest du möglicherweise weitere Rollen und Berechtigungen zu jeder Organisation hinzufügen. Zum Beispiel eine neue Rolle "Gast" und eine neue Berechtigung "einladen:Gast". Es könnte ein Albtraum sein, wenn du alle bestehenden Organisationen einzeln aktualisieren müsstest.

Mit Logto kannst du das Organisationstemplate aktualisieren, und alle bestehenden Organisationen werden automatisch aktualisiert.

Ein Zugriffssteuerungsmodell, mehrere Anwendungsfälle#

In Logto verwenden wir dasselbe Zugriffssteuerungsmodell (RBAC) für Organisationen und API-Ressourcen. Das bedeutet, dass du kein neues Zugriffssteuerungsmodell erlernen musst, wenn du bereits mit RBAC vertraut bist. Gleichzeitig sind sie voneinander isoliert, sodass du sie für unterschiedliche Anwendungsfälle verwenden kannst.

Das Spannendste ist, dass du sie gleichzeitig verwenden kannst. Erweitern wir das Notion-Beispiel:

• Für den Zugriff auf Arbeitsbereiche kannst du Logto Organisations-RBAC verwenden.
• Für den Zugriff auf und die Aktualisierung von ressourcenbezogenen Daten auf Kontoebene (wie Profil- und Abrechnungsinformationen) kannst du Logto API-Ressourcen-RBAC verwenden.

Die meisten Logto SDKs unterstützen beide Arten von RBAC.

Die Unterschiede

Organisations-RBAC und API-Ressourcen-RBAC unterscheiden sich in den folgenden Aspekten:

• Organisations-RBAC erfordert den Kontext einer Organisation, während API-Ressourcen-RBAC dies nicht tut.
• Organisations-RBAC wird verwendet, um den Zugriff innerhalb einer Organisation zu steuern, während API-Ressourcen-RBAC verwendet wird, um den Zugriff auf API-Ressourcen zu steuern.
• Ein Benutzer kann unterschiedliche Organisationsrollen in verschiedenen Organisationen haben, während die Rollen für API-Ressourcen im gesamten Mandanten universell sind.
• Rollen und Berechtigungen sind für diese beiden Arten von RBAC isoliert.

Abschließende Anmerkungen#

Eine SaaS-App zu entwickeln ist schwer, und wir hoffen, dass Logto dir hilft, dich auf dein Kerngeschäft zu konzentrieren. Zögere nicht, uns Feedback zu geben, wenn du Fragen oder Vorschläge hast.