Kapitel 4. Onboarding und Identität

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Nachdem du nun ein Gefühl für die breitere Multi-Tenant-Terminologie und -Landschaft bekommen hast, wollen wir uns ansehen, was es bedeutet, diese Konzepte in einer funktionierenden Lösung zum Leben zu erwecken. Die Frage ist: Wo soll man anfangen? So viele Teams stellen mir diese Frage. Glücklicherweise gibt es auf diesen Bereich eine ziemlich einheitliche Antwort. Unabhängig davon, ob es sich um eine Migration oder eine Neuentwicklung handelt, würde ich als Ausgangspunkt für den Aufbau der meisten mandantenfähigen Architekturen immer das Onboarding, die Identität und die Kontrollebene nennen. Jedes dieser Elemente erzwingt wichtige, grundlegende Konstrukte in deiner Umgebung, die definieren, wie Tenants eingeführt werden und wie Nutzer erstellt und an Tenants gebunden werden. Mit diesen ersten Schritten werden die Bausteine unserer Steuerungsebene festgelegt.

Indem du hier beginnst, rückst du die Mandantenfähigkeit in den Mittelpunkt. Das bedeutet, dass alle Schichten deiner Architektur nun gezwungen sind, sich mit dem Thema Mandantenfähigkeit auseinanderzusetzen. Jede Komponente deines Systems muss nun berücksichtigen, wie sich die Mandantenfähigkeit auf ihr Design und ihre Implementierung auswirken kann. Das mag wie eine subtile Nuance erscheinen, aber die Auswirkungen sind ziemlich tiefgreifend. Das bloße Vorhandensein von Mietverhältnissen wirkt sich darauf aus, wie du Mieter/innen isolierst, wie du ihre Daten darstellst, wie du mehrere Personas unterstützt, wie du Mieter/innen abrechnest und viele andere Aspekte deiner Lösung. Außerdem wird damit eine klare Grenze zwischen der Kontroll- und der Anwendungsebene gezogen. Ziel ist es, zu vermeiden, dass du in die Falle tappst, mit der Anwendung zu beginnen und die Mieterschaft erst im Nachhinein hinzuzufügen. Das funktioniert nie gut und führt in der Regel zu erheblichen Umstrukturierungen und Kompromissen, die das Design deiner SaaS-Architektur untergraben.

Zu Beginn des Kapitels werden wir uns ansehen, was nötig ist, um die Grundlagen unserer Steuerungsebene zum Laufen zu bringen. Hier geht es um die Bereitstellung der Infrastruktur und der Ressourcen, die benötigt werden, um die verschiedenen Dienste zu hosten, die für die Verwaltung und den Betrieb deiner SaaS-Architektur benötigt werden. Auch wenn diese Kontrollebene letztendlich viele Dienste beherbergen wird, werde ich mich in diesem Kapitel hauptsächlich auf das Onboarding und die Identitätsfunktionen konzentrieren. Später werden wir dann sehen, wie wir weitere Aspekte der Kontrollebene aufbauen.

Wenn wir uns mit dem Onboarding befassen, bekommst du einen besseren Überblick über alle beweglichen Teile, die Teil dieses Prozesses sind. In manchen Umgebungen kann die Steuerung dieses Prozesses ziemlich komplex sein. Auch wenn die Art des Onboarding in jeder SaaS-Umgebung unterschiedlich sein kann, gibt es doch einige gemeinsame Themen, die sich durch viele Implementierungen ziehen. Ich werde einige dieser Themen näher beleuchten, indem ich dich durch einen beispielhaften Onboarding-Prozess führe. Dabei werden einige der Überlegungen deutlich, die du beim Aufbau deines eigenen Onboarding-Dienstes anstellen solltest. Außerdem wird deutlich, welche wichtige Rolle das Onboarding in deiner SaaS-Architektur spielt.

Der nächste Bereich, auf den ich eingehen werde, ist die Identität. Ich werde näher darauf eingehen, wie wir einzelne Nutzer an Tenants binden, um zu dem in Kapitel 1 besprochenen Tenant-Kontext zu gelangen. Dazu gehören auch die spezifischen Identitätsmechanismen, die es uns ermöglichen, die Authentifizierung der Tenants zu gestalten und den Tenant-Kontext in die Anfragen zu integrieren, die durch alle Backend-Dienste deiner SaaS-Anwendung fließen. Wir werden sehen, wie dieser Kontext die Art und Weise beeinflusst, wie Teams die Multi-Tenant-Funktionen ihrer SaaS-Architektur aufbauen und verwalten.

Wenn du all diese grundlegenden Konzepte zusammen betrachtest, wird dir klarer, wie wichtig es ist, sich mit diesen Konzepten von Anfang an auseinanderzusetzen. Ziel ist es, dich mit den wichtigsten Strategien, Mustern und Überlegungen vertraut zu machen, ohne dabei zu sehr auf die Besonderheiten einer bestimmten Technologie einzugehen. Wenn du diese Kernkonzepte verstehst, wirst du wissen, wie du viele der Multi-Tenant-Themen, die wir in den folgenden Kapiteln behandeln werden, angehen kannst.

Erstellen einer grundlegenden Umgebung

Um diese Reise zu beginnen, möchte ich das Onboarding und die Identität so angehen, als ob wir bei Null anfangen würden. Das soll dir ein besseres Gefühl dafür geben, wie du diese Strategien von Grund auf umsetzen kannst. Das bedeutet, dass wir von den Besonderheiten des Onboarding und der Identität einen Schritt zurücktreten und uns zunächst überlegen müssen, welche Grundlagen wir schaffen müssen, bevor wir mit dem Onboarding von Mietern beginnen können. Die Dienste, die das Onboarding unterstützen, laufen innerhalb der Control Plane. Wir müssen also zunächst alle Teile einrichten, die für die Ausführung der Microservices auf der Control Plane benötigt werden, die das Onboarding und die Identität unterstützen.

Die Erstellung der Infrastruktur, der abhängigen Ressourcen und der Kontrollebene bezeichne ich als Erstellen einer Basisumgebung. Im Wesentlichen müssen wir die Skripte und die Automatisierung erstellen, die es uns ermöglichen, alle für das Hosting unserer SaaS-Umgebung erforderlichen Konstrukte in Betrieb zu nehmen. Während unser Ziel darin besteht, das Onboarding und die Identität zum Laufen zu bringen, umfasst der Umfang der Basisumgebung alle Ressourcen, die einmalig bereitgestellt werden müssen, um unsere mandantenfähige Umgebung einzurichten, bevor wir mit dem Onboarding beginnen. Das bedeutet, dass wir einige Ressourcen einrichten werden, die über das Tenant Onboarding und die Identität hinausgehen. Wir werden uns jetzt nicht auf diese anderen Dinge konzentrieren, aber es ist wichtig zu wissen, dass eine Basisumgebung all diese Konzepte umfasst.

Die eigentliche Erstellung unserer Baseline-Umgebung erfolgt über ein klassisches DevOps-Modell, bei dem Tools zur Infrastrukturautomatisierung eingesetzt werden, um alle für unsere Baseline-Umgebung erforderlichen Ressourcen zu erstellen, zu konfigurieren und bereitzustellen. Abbildung 4-1 zeigt einen Überblick über diese Erfahrung.

Die Grundidee ist, dass du das DevOps-Tool bzw. die DevOps-Tools auswählst, die zu deiner Umgebung passen, und ein einziges, wiederholbares Automatisierungsmodell erstellst, mit dem du alles konfigurieren kannst, was du brauchst, um deine Umgebung in einen Zustand zu versetzen, in dem sie mit dem Onboarding von Mietern beginnen kann.

Was sich tatsächlich in deiner Basisumgebung befindet, hängt natürlich stark von der Art des spezifischen Technologie-Stacks ab, den du für deine SaaS-Lösung verwendest. Ein Kubernetes-Stack kann zum Beispiel ganz anders aussehen als ein Serverless-Stack. Auch die Feinheiten der verschiedenen Cloud-Provider beeinflussen den Bereitstellungsprozess. Wir werden uns weitere spezifische Beispiele ansehen, um zu sehen, wie sie abschneiden, aber jetzt wollen wir uns erst einmal darauf konzentrieren, was in diesem Schritt bereitgestellt werden muss, damit unser System mit dem Onboarding von Mietern beginnen kann.

Erstellen deiner Basisumgebung

Um eine bessere Vorstellung davon zu bekommen, was in dieser Basisumgebung enthalten ist, sehen wir uns ein Beispiel dafür an, was bereitgestellt, konfiguriert und eingesetzt werden könnte, um deine Basisumgebung zum Leben zu erwecken. In Abbildung 4-2 siehst du, dass ich eine konzeptionelle Ansicht der Komponenten und der Infrastruktur zusammengestellt habe, die in einer Baseline-Umgebung erstellt werden könnten. Das Ziel war es, einige der wichtigsten Konzepte der Basisinfrastruktur darzustellen, ohne sich zu sehr in den Details einer bestimmten Technologie zu verlieren.

In der Mitte von Abbildung 4-2 siehst du, dass ich die grundlegende Netzwerkinfrastruktur erstellt habe, die für das Hosting meiner mandantenfähigen SaaS-Umgebung benötigt wird. Für dieses Beispiel habe ich einfach einige gängige AWS-Netzwerkkonstrukte (eine VPC, Availability Zones und einige Subnetze) genommen, um das Hochverfügbarkeitsnetzwerk darzustellen, das meine SaaS-Umgebung hosten wird. Dieselben Netzwerkkonstrukte können auf eine beliebige Anzahl verschiedener Technologien abgebildet werden. In diesem Stadium ist es wichtig, sich auf die Tatsache zu konzentrieren, dass du für die Konfiguration und Einrichtung dieser Basisumgebung alle wichtigen Netzwerkkonstrukte bereitstellen und konfigurieren musst, die von deiner Control Plane und möglicherweise auch von deinen Tenants verwendet werden.

In diesem Netzwerk habe ich auch die Bereitstellung der Steuerebene gezeigt. Da die Control Plane von allen Tenants gemeinsam genutzt wird, kann sie im Rahmen der Einrichtung deiner Basisumgebung konfiguriert und bereitgestellt werden. Die Control Plane muss ebenfalls vorhanden sein, damit wir mit dem Onboarding der Tenants und der Einrichtung ihrer Identität beginnen können. Um die Sache zu vereinfachen, habe ich hier nur einige Dienste aufgeführt. In Wirklichkeit umfasst die Liste der Dienste der Control Plane eine viel größere Bandbreite. Wir werden uns diese Dienste genauer ansehen, wenn wir anfangen, uns mit konkreteren Lösungen zu beschäftigen.

Auf der unteren rechten Seite von Abbildung 4-2 siehst du außerdem eine Sammlung von gepoolten Ressourcen. Die Elemente hier sind die konzeptionellen Platzhalter für alle Ressourcen, die von den Tenants gemeinsam genutzt werden können. Wenn du gepoolte Ressourcen hast, die von allen Tenants gemeinsam genutzt werden sollen, kannst du sie in der Regel während der Einrichtung deiner Basisumgebung bereitstellen (da sie nicht während des Onboarding-Prozesses erstellt werden müssen). Ein gutes Beispiel hierfür ist die Speicherung. Stell dir vor, du hast eine gepoolte Datenbank für einen Microservice in deiner Lösung. Wenn sie gepoolt ist, kann sie erstellt werden, wenn die Basisumgebung bereitgestellt wird. Du wirst auch die Einrichtung eines gemeinsamen Identitätskonstrukts und einer gepoolten Nachrichtenwarteschlange sehen. Auch hier geht es nur darum, dass du dir überlegst, ob du diese bei der Einrichtung deiner Basisumgebung einrichten solltest. Auf einige der Kompromisse gehe ich später in diesem Kapitel ein, wenn wir uns mit dem Onboarding von Mandanten befassen.

Oben rechts habe ich Platzhalter für die Systemadministrator-Identität und die Administrationskonsole eingefügt. Das sind die Benutzer, die sich bei den speziellen Tools anmelden, die du für die Unterstützung, Aktualisierung, Konfiguration und allgemeine Verwaltung deiner mandantenfähigen Architektur eingerichtet hast. Ich bezeichne dieses gezielte Tooling als deine Systemadministrationskonsole. Diese Konsole ist die zentrale Anlaufstelle für deine SaaS-Umgebung und bietet deinem Team eine speziell entwickelte Sammlung von Funktionen und Möglichkeiten, die für den Betrieb deiner mandantenfähigen Umgebung unerlässlich sind. Selbst mit diesen anderen Tools benötigen die meisten SaaS-Teams eine eigene, maßgeschneiderte Verwaltungsanwendung, die die spezifischen Multi-Tenant-Anforderungen ihrer Umgebung erfüllen kann .

Abbildung 4-3 zeigt einen Schnappschuss einer einfachen SaaS-Administrationskonsolen-Anwendung, um dieses Konzept zu verdeutlichen. Über diese Anwendung hast du Zugang zu allen wichtigen Informationen über deine SaaS-Lösung. Du kannst den Status des Onboarding von Tenants überwachen, Tenants aktivieren/deaktivieren, Tenant-Richtlinien verwalten, Tenant-/Tier-Metriken einsehen und alle anderen Funktionen nutzen, die für die Verwaltung und den Betrieb deiner SaaS-Lösung erforderlich sind. Diese Anwendung muss im Rahmen der Einrichtung deiner Basisumgebung konfiguriert und implementiert werden.

Es ist erwähnenswert, dass einige Teams dazu neigen, zu wenig in ihre Verwaltungskonsolen zu investieren und lieber auf vorgefertigte Lösungen zurückgreifen, als selbst etwas zu entwickeln. Dieser Kompromiss lohnt sich in der Regel nicht. Du kannst zwar Lösungen von Drittanbietern verwenden, um eine Konsole zusammenzustellen, aber es gibt bestimmte Vorgänge, Einblicke und Konfigurationsoptionen, die nur durch die Erstellung einer zielgerichteten Konsole effektiv genutzt werden können.

Erstellen und Verwalten von Systemadministrator-Identitäten

Bei der Einrichtung deiner Basisumgebung und der Konfiguration deiner Verwaltungsanwendung musst du auch das Identitätsmodell deines Systemadministrators einrichten. Jedes Mal, wenn du die Erstellung einer Baseline-Umgebung anstößt, musst du das Profil des ersten administrativen Benutzers angeben, der sich bei deiner Verwaltungskonsole anmelden kann. Die Erstellung dieser Identität ist völlig unabhängig von der Erstellung einer Tenant-Identität. Das bedeutet auch, dass du eine völlig separate Authentifizierung brauchst, damit diese Systemadministratoren auf die Verwaltungskonsole oder andere Befehlszeilentools zugreifen können, die du zur Verwaltung deiner Multi-Tenant-Umgebung verwendest.

Um diese Systemadministrator-Identität zu unterstützen, brauchst du einen Identitätsanbieter, der diese Benutzer besitzt und authentifiziert. Der Identitätsprovider, den du hier verwendest, könnte derselbe sein, der auch für deine Mandantenidentitäten verwendet wird. Es kann aber auch ein separater Identitätsanbieter sein, der im Rahmen einer globalen Unternehmensverwaltungsstrategie verwendet wird. Unabhängig davon, welchen Identitätsanbieter du verwendest, sind die grundlegenden Mechanismen zur Einführung einer Systemadministratoridentität sehr ähnlich.

Die wichtigste Erkenntnis ist, dass du einige Schritte in deiner Basisautomatisierung für die Bereitstellung benötigst, um dein Identitätsmodell für die Systemverwaltung zu erstellen und zu konfigurieren. Diese Automatisierung umfasst die Erstellung und Konfiguration des Identitätsanbieters sowie die Erstellung der ersten Systemadministrationsbenutzer. Sobald der Benutzer eingerichtet ist, solltest du mit dieser Identität auf deine Systemadministrationskonsole zugreifen können. Sobald du in der Systemadministrationskonsole angekommen bist, kannst du weitere Systemadministrationsbenutzer verwalten und erstellen.

Das Beispiel in Abbildung 4-3 zeigt eine Ansicht der Benutzerverwaltung für Systemadministratoren. Hier habe ich auf die Konsole zugegriffen und mich dort authentifiziert, nachdem ich meine Umgebung eingerichtet habe. Auf dieser Seite kann ich nun andere Systemadministratoren erstellen und verwalten.

Onboarding über die Admin-Konsole auslösen

Sobald du deinen Systemadministrator eingerichtet und deine Verwaltungskonsole zum Laufen gebracht hast, hast du alle Voraussetzungen geschaffen, um Mieter anzulegen und einzubinden. In der endgültigen Version deines Angebots kann das Onboarding als Teil eines Self-Service-Angebots aufgerufen werden, oder es kann durch einen internen Prozess gesteuert werden. Wenn es sich um einen internen Prozess handelt, möchtest du natürlich deine Systemadministrationskonsole nutzen, um das Onboarding zu verwalten. Das bedeutet, dass du in deiner Konsole einen Vorgang einrichten musst, der alle Daten eines neuen Tenants sammelt, bevor du den Onboarding-Vorgang aufrufst.

Einige Teams finden es sehr nützlich, dass sie die Mieter über die Verwaltungskonsole des Systems anwerben können. Selbst wenn das Onboarding letztendlich ein Self-Service-Modell sein sollte, kannst du das Onboarding von der Verwaltungskonsole aus testen und validieren. Das kann besonders für Teams hilfreich sein, die das Onboarding-Erlebnis ihrer Anwendung validieren und testen.

Optionen für die Bereitstellung der Control Plane

In Abbildung 4-2 habe ich gezeigt, dass die Steuerebene in der gleichen Basisinfrastruktur installiert wird, in der auch deine Mieter landen würden. Das ist eine durchaus sinnvolle Option. Es ist jedoch zu beachten, dass die Art und Weise, wie und wo die Control Plane platziert wird, von den Anforderungen deiner Umgebung und dem für deine Multi-Tenant-Architektur verwendeten Technologie-Stack abhängen kann. In Kubernetes könnte ich zum Beispiel einen separaten Namensraum für die Control Plane einrichten und meine Tenant-Umgebungen neben der Control Plane im selben Cluster und in derselben Netzwerkinfrastruktur platzieren. Ich könnte mich auch dafür entscheiden, die Control Plane in einer völlig separaten Infrastruktur zu platzieren, die nur für die Control Plane bestimmt ist.

Abbildung 4-4 zeigt eine konzeptionelle Darstellung dieser beiden Optionen. Auf der linken Seite siehst du das Modell der geteilten Kontrollebene, bei dem die Kontrollebene in derselben Umgebung wie deine Tenant-Infrastruktur eingesetzt wird. Auf der rechten Seite siehst du einen Ansatz, bei dem die Control Plane in einer eigenen Umgebung untergebracht wird. Hier laufen die Tenants in einem völlig separaten Netzwerk oder Cluster, das eine härtere Grenze zwischen der Kontroll- und der Anwendungsebene zieht.

Die Kompromisse zwischen diesen beiden Möglichkeiten sind ziemlich einfach. Du könntest dich für eine eigene Control-Plane-Umgebung entscheiden, wenn du diese Umgebungen völlig unabhängig skalieren, verwalten und betreiben möchtest. Auch die Einhaltung von Vorschriften kann hier eine Rolle spielen; diese Anforderungen oder deine Domäne lassen sich vielleicht besser erfüllen, wenn du die Kontroll- und Anwendungsbereiche stärker voneinander trennst. Wenn du die Control Plane in derselben Umgebung wie die Application Plane unterbringst, vereinfacht das die Dinge natürlich ein wenig. Die Anzahl der beweglichen Teile, die du verwalten, konfigurieren und bereitstellen musst, wird dadurch reduziert. Das kann auch deine Kosten reduzieren. Wenn du dich für das dedizierte Modell entscheidest, musst du entscheiden, wie du diese getrennten Konstrukte integrieren willst, damit die Control Plane mit deiner Application Plane interagieren kann.

Die Wahl deines Technologie-Stacks kann sich auch darauf auswirken, wie du deine Kontrollebene einsetzt. Manche Teams entscheiden sich zum Beispiel für unterschiedliche Technologie-Stacks für die Kontroll- und die Anwendungsebene. Ich würde mich zum Beispiel für Serverless für die Kontrollebene und Container für die Anwendungsebene entscheiden. Das könnte dich mehr in Richtung eines dedizierten Control-Plane-Modells lenken.

Das Onboarding-Erlebnis

Nachdem unsere Basisumgebung nun eingerichtet und konfiguriert ist, können wir uns dem Onboarding der Mieter zuwenden. Beim Onboarding wirst du feststellen, dass du einige der grundlegendsten Elemente einer Multi-Tenant-Architektur einführst und anwendest. Wenn ich mit SaaS-Kunden auf der grünen Wiese oder bei der Migration arbeite, schlage ich ihnen immer vor, sich zunächst auf den Onboarding-Prozess zu konzentrieren.

Schon hier müssen die Teams viele schwierige Fragen beantworten, die den Rest ihrer SaaS-Architektur beeinflussen und prägen werden. Beim Onboarding geht es nicht nur darum, einen Tenant zu erstellen. Es geht auch darum, alle beweglichen Teile der Infrastruktur zu erstellen und zu konfigurieren, die für die Unterstützung des neuen Mandanten erforderlich sind. In manchen Fällen kann das eine leichte Übung sein, in anderen Fällen kann es eine beträchtliche Menge an Code erfordern, um jeden Schritt im Onboarding-Prozess zu steuern. Wie deine Tenants gestaffelt sind, wie sie sich authentifizieren, wie ihre Richtlinien verwaltet werden, wie ihre Isolierung konfiguriert ist, wie sie weitergeleitet werden - das sind alles Bereiche, die von der Onboarding-Erfahrung deiner Multi-Tenant-Umgebung betroffen sind.

Onboarding ist Teil deines Service

Viele Teams tappen in die Falle , dass sie das Onboarding als etwas betrachten, das nach der Erstellung des Systems aufgeschraubt wird. Sie erstellen Platzhalter und Workarounds, um das Onboarding-Erlebnis zu simulieren, mit dem Gedanken, dass sie es später im Prozess "echt" machen können. Damit sind wir wieder bei der Diskussion über den Vergleich zwischen einer Dienstleistung und einem Produkt. In einer SaaS-Umgebung wird das Onboarding nicht als ein Skript oder eine Automatisierung betrachtet, die irgendwie außerhalb des Rahmens deines Angebots liegt. Stattdessen ist es eine der grundlegendsten Komponenten deines SaaS-Erlebnisses und es richtig zu machen, sollte für jedes Team, das eine mandantenfähige Lösung entwickelt, von zentraler Bedeutung sein.

Das Onboarding steht im Mittelpunkt deiner geschäftlichen und technischen Prioritäten. Die Erfahrung, die jeder Kunde mit dem Onboarding macht, kann einen tiefgreifenden Einfluss auf den allgemeinen Erfolg des Unternehmens haben. Wie reibungslos, effizient und zuverlässig dieser Prozess abläuft, wirkt sich direkt auf die Erfahrung und die Wahrnehmung der Kunden aus, die dein Produkt nutzen. Es ist deine Chance, einen positiven ersten Eindruck zu hinterlassen. Das Onboarding-Erlebnis steht auch in direktem Zusammenhang mit dem Begriff "Time to Value", also der Zeit, die ein Kunde braucht, um von der Anmeldung bis zur tatsächlichen Produktivität und Nutzung deines SaaS-Angebots zu gelangen. Jede zusätzliche Reibung, die hier auftritt, wirkt sich auf den Eindruck aus, den du als Dienstleistung hinterlässt, und könnte deine Fähigkeit beeinflussen, Kunden von Adoptern zu Promotern zu machen.

Das Onboarding ist auch der Ort, an dem die Strategien für Bereitstellung, Identität, Routing und Tiering in die Tat umgesetzt werden. Die Art und Weise, wie Tenants in Silos und Pools untergebracht werden, muss direkt durch das Onboarding-Erlebnis ausgedrückt und umgesetzt werden. Wie und wo du deine Mieter authentifizierst, wird im Rahmen des Onboardings konfiguriert und angewendet. Im Rahmen des Onboardings wird auch konfiguriert, wie deine Tenants je nach Tier und Bereitstellungsmodell kontextbezogen weitergeleitet werden. Viele dieser wichtigen Entscheidungen, die du in deiner SaaS-Architektur triffst, werden letztendlich durch den Onboarding-Prozess deines Systems zum Ausdruck gebracht und mit Leben gefüllt. In vielerlei Hinsicht sind deine Onboarding-Konfiguration, deine Automatisierung und dein Bereitstellungscode der Dreh- und Angelpunkt für die Umsetzung der Multi-Tenant-Strategien, die du für deine SaaS-Umgebung anwendest .

Die Menge an Aufwand und Code, die für die Automatisierung des Onboardings erforderlich ist, mag für einige Teams überraschend sein. Es ist nicht ungewöhnlich, dass SaaS-Teams den Aufwand und die Investitionen unterschätzen, die mit dem Aufbau eines stabilen Onboarding-Erlebnisses verbunden sind. In Wirklichkeit ist das Onboarding eines der wichtigsten Elemente einer mandantenfähigen Umgebung. Durch das Onboarding kannst du die operativen und agilen Ziele erreichen, die für ein SaaS-Unternehmen unerlässlich sind.

Selbstbedienung versus internes Onboarding

Bis jetzt mag es so aussehen, als ob diese Diskussion über Onboarding hauptsächlich Mechanismen beschreibt, die von Organisationen genutzt werden, die sich auf eine Selbstbedienungsanmeldung verlassen. Viele von uns haben sich schon bei unzähligen B2C-SaaS-Angeboten angemeldet, bei denen wir ein Formular ausgefüllt, unsere Daten übermittelt und dann einen SaaS-Dienst genutzt haben. Diese klassische Form des Onboarding liegt zwar in unserem Bereich, aber wir müssen auch Szenarien in Betracht ziehen, in denen unser Onboarding-Prozess kein Selbstbedienungsmodell unterstützt. Stell dir z. B. einen B2B-SaaS-Anbieter vor, der erst dann in dein System einsteigt, wenn du einen Vertrag mit ihm abgeschlossen hast und ihm zustimmst. Diese SaaS-Anbieter haben vielleicht nur eine gewisse Erfahrung mit dem intern verwalteten Onboarding.

Ich will damit sagen, dass Onboarding nicht an eine bestimmte Erfahrung gebunden ist. Du kannst ein Self-Service-Onboarding oder ein internes Onboarding verwenden. Jede SaaS-Lösung, unabhängig davon, wie sie ihr Onboarding-Erlebnis präsentiert, muss sich an denselben Werten orientieren. Für mich ist die Messlatte für Self-Service und intern verwaltete Onboarding-Prozesse dieselbe. Beide Ansätze sollten einen vollautomatischen, wiederholbaren und reibungsarmen Onboarding-Prozess schaffen, der sich darauf konzentriert, die Zeit bis zur Wertschöpfung für den Kunden zu maximieren. Ja, es kann sein, dass jemand aus dem operativen Geschäft deinen internen Prozess durchführt. Das bedeutet aber nicht, dass du von diesem Onboarding-Prozess weniger Automatisierung, Skalierbarkeit oder Beständigkeit erwartest.

Bei jedem SaaS-System, das ich aufbaue, möchte ich sicher sein, dass ich das Onboarding-Erlebnis als einen wichtigen Teil meines Systems betrachte. Sie steht im Mittelpunkt, um sicherzustellen, dass ich einen konsistenten, wiederholbaren, automatisierten Onboarding-Mechanismus habe, der gewährleistet, dass jeder neue Mieter ohne manuelle Prozesse oder einmalige Konfiguration eingeführt wird.

Die grundlegenden Teile des Onboarding

Nachdem du nun ein besseres Gefühl für die Bedeutung des Onboarding-Prozesses bekommen hast, wollen wir uns den Details der zugrundeliegenden Komponenten des Onboarding-Erlebnisses zuwenden. Es gibt zwar viele Details bei der Umsetzung des Onboarding-Prozesses, aber mein Ziel ist es, dir einen Überblick über die Kernkomponenten dieses Prozesses zu geben und die Leitprinzipien zu skizzieren, die dieses Erlebnis typischerweise prägen.

Abbildung 4-5 zeigt eine konzeptionelle Übersicht über die beweglichen Teile eines Multi-Tenant-Onboarding-Erlebnisses.

Auf der linken Seite siehst du unter zwei gängige Muster, die für einen Onboarding-Prozess verwendet werden können. Zunächst habe ich einen Tenant-Administrator gezeigt, der das Onboarding über einen Self-Service-Anmeldeprozess durchführt, vermutlich über eine Webanwendung, die es dem Tenant ermöglicht, seine Daten zu übermitteln, einen Plan auszuwählen und alle Konfigurationsinformationen anzugeben, die er benötigt, um sich als neuer Tenant im System einzurichten. Ich habe auch einen zweiten Onboarding-Prozess gezeigt, der in diesem Beispiel von einem Systemadministrator initiiert wird. Dabei handelt es sich um eine interne Funktion beim SaaS-Anbieter, die eine Administrationskonsole (oder ein anderes Tool) verwendet, um die Onboarding-Daten für einen neuen Tenant einzugeben und den Onboarding-Prozess auszulösen. In diesem Beispiel habe ich beide Onboarding-Pfade berücksichtigt. In den meisten Fällen wird eine SaaS-Organisation jedoch einen dieser beiden Ansätze unterstützen. Ich habe hier nur beide aufgezeigt, um zu verdeutlichen, dass das Onboarding unabhängig vom Einstiegspunkt ein vollständig automatisierter Prozess für jeden dieser beiden Anwendungsfälle sein sollte.

Bei diesen Onboarding-Pfaden siehst du, dass sie beide eine Onboarding-Anfrage an den Onboarding-Dienst senden (Schritt 1). Für das Onboarding bevorzuge ich in der Regel einen einzigen Onboarding-Dienst, der die gesamte Orchestrierung des Onboardings übernehmen kann. Dieser Dienst ist für den gesamten Lebenszyklus des Onboarding-Prozesses zuständig und sorgt dafür, dass alle Schritte des Prozesses erfolgreich abgeschlossen werden. Dies ist besonders wichtig, da einige Aspekte des Onboarding-Prozesses asynchron ablaufen oder von Integrationen Dritter abhängig sind, die Probleme mit der Verfügbarkeit haben könnten.

Der Onboarding-Prozess ruft dann eine Reihe von verteilten Diensten auf, mit denen die Einstellungen und die unterstützende Infrastruktur des Mandanten erstellt und konfiguriert werden . Die Abfolge dieses Onboarding-Prozesses kann je nach Art deiner SaaS-Anwendung variieren. Im Allgemeinen besteht das Ziel darin, alle erforderlichen Tenant-Assets zu erstellen und zu konfigurieren, bevor der Tenant aktiv wird und/oder der Tenant-Administrator darüber informiert wird, dass sein Konto aktiv ist.

Es gibt zwar mehrere Möglichkeiten, diesen Onboarding-Flow zu implementieren, aber du musst mit der Erstellung einer Tenant-Kennung beginnen. In unserem Beispiel wird dieser Tenant Identifier erstellt, indem du eine Anfrage zum Erstellen eines Tenants an , den Tenant Management Service, sendest (Schritt 2) und dabei alle Informationen über unseren Tenant übermittelst (Unternehmensname, Identitätskonfiguration, Stufe usw.). Außerdem wird ein eindeutiger Identifikator für unseren Tenant erstellt. Teams verwenden oft einen global eindeutigen Bezeichner (GUID) als Wert für ihren Tenant-Bezeichner und vermeiden so die Einbeziehung von Attributen, die mit dem Namen oder anderen identifizierenden Informationen über den Tenant verbunden sein könnten. Dadurch wird verhindert, dass jemand einen Tenant mit einem bestimmten Identifikator in Verbindung bringen kann. Dieser Tenant wird auch mit einer Art "aktivem" Status erstellt, der den aktuellen Zustand des Tenants verwaltet. In diesem Fall, dem Onboarding, wird der aktive Status zunächst auf false gesetzt. Sobald das System diesen Tenant erstellt hat, hast du einen Tenant-Identifikator, der für den Rest des Onboarding-Prozesses verwendet werden kann. Auf den Dienst Tenant Management und seine Rolle in der Kontrollebene gehe ich in Kapitel 5 näher ein.

Der nächste Schritt in unserem Beispiel für das Tenant Onboarding ist die Bereitstellung der erforderlichen Ressourcen für den Tenant (Schritt 3). Dieser Bereitstellungsschritt kann bei einigen Multi-Tenant-Architekturen einer der wichtigsten Bestandteile deiner Onboarding-Implementierung sein. Bei einer Full-Stack-Silo-Implementierung kann dies zum Beispiel bedeuten, dass eine komplett neue Sammlung von Infrastruktur- und Anwendungsdiensten bereitgestellt wird. Im Gegensatz dazu erfordert eine Full-Stack-Pool-Umgebung möglicherweise nur eine minimale Bereitstellung und Konfiguration der Infrastruktur.

Wenn wir uns mehr Arbeitsbeispiele ansehen, wirst du vielleicht überrascht sein, wie viel Code und Automatisierung in dieses Onboarding-Erlebnis fließt. Tatsächlich ist dies oft ein Bereich, in dem SaaS-Systeme die Grenzen von DevOps verwischen. Während sich in traditionellen Umgebungen ein Großteil des DevOps-Lebenszyklus auf die Bereitstellung und Aktualisierung der Basisinfrastruktur konzentriert, kann in SaaS-Umgebungen die Ausführung von DevOps-Code während des Onboardings jedes einzelnen Tenants erforderlich sein. Dein System muss möglicherweise neue Infrastrukturen zur Laufzeit bereitstellen und konfigurieren, um die Erstellung einer isolierten Tenant-Infrastruktur zu verarbeiten. Wie du dir vorstellen kannst, bringt dies neue Überlegungen und Denkweisen mit sich, wie du den gesamten DevOps-Footprint deiner Multi-Tenant-Lösung organisierst und aufbaust. Für einige bedeutet dies eine neue Denkweise und neue Ansätze für die Werkzeuge, die zur Bereitstellung von Tenant-Umgebungen verwendet werden.

In diesem Stadium haben wir einen Tenant erstellt und unsere Tenant-Ressourcen sind bereitgestellt. Jetzt können wir diesen neuen Tenant dem Abrechnungssystem hinzufügen (Schritt 4). Hier gibst du dem Abrechnungssystem Informationen zur Identifizierung des neuen Tenants und alle Informationen, die für das Abrechnungsmodell benötigt werden, das auf diesen bestimmten Tenant angewendet werden soll. Wir gehen davon aus, dass du vor dem Onboarding eines neuen Mieters die verschiedenen Ebenen oder Abrechnungspläne konfiguriert und eingerichtet hast, die das allgemeine Preismodell deiner Lösung bestimmen. Während des Onboardings ordnet dein Abrechnungsservice dann das Onboarding-Profil des Tenants dem entsprechenden (vorkonfigurierten) Abrechnungstarif zu.

Du wirst feststellen, dass in Abbildung 4-5 ein separater Billing-Provider aufgeführt ist. Die Idee dahinter ist , dass dein Billing Service die Integration mit deinem Abrechnungssystem verwaltet und koordiniert. In vielen Fällen wird dieser Billing Provider von einem Drittsystem unterstützt. In diesen Fällen kann es sinnvoll sein, einen separaten Abrechnungsdienst zwischen deinem Onboarding-Prozess und dem Abrechnungsdienstleister einzuschalten, damit du alle Besonderheiten, die für die Unterstützung eines bestimmten Abrechnungsdienstleisters erforderlich sind, berücksichtigen kannst. In anderen Fällen kannst du deinen Onboarding-Dienst direkt mit dem Abrechnungsdienstleister verbinden. Einige SaaS-Unternehmen verwenden auch ein internes Abrechnungssystem. Auch in diesem Fall solltest du deinen Onboarding-Prozess nach einem ähnlichen Muster integrieren. Es gibt noch viel mehr zu bedenken, was die Rechnungsstellung angeht (außerhalb des Onboarding-Prozesses). Auf diese Details gehe ich in Kapitel 14 näher ein .

Für den letzten Teil des Onboarding müssen wir den Tenant-Admin-Benutzer erstellen (Schritt 5). Wenn du dich erinnerst, ist die Tenant-Admin-Rolle der erste Benutzer, der für einen bestimmten Tenant erstellt wird. Dieser Mieter hat die Möglichkeit, weitere Benutzer anzulegen, die auf das System zugreifen können. In diesem Stadium ist unser Hauptziel jedoch, diesen ersten Benutzer innerhalb unseres Identitätsanbieters zu erstellen, damit unser Mandant sich authentifizieren und auf seine bereitgestellte Umgebung zugreifen kann. Hier musst du dich auf die Funktionen deines Identitätsanbieters verlassen, um die Benachrichtigung und Validierung dieses neuen Mandanten zu organisieren. Die meisten Identitätsanbieter unterstützen die Erstellung einer E-Mail-Nachricht, die eine URL und ein temporäres Passwort für den Zugang zum System enthält. Dieser Prozess veranlasst dann den authentifizierenden Nutzer, im Rahmen des Anmeldevorgangs ein neues Passwort einzugeben. Das Ziel ist es, die Automatisierung dieses Anmeldeprozesses weitgehend auf deinen Identitätsanbieter zu übertragen. Verlasse dich darauf, dass diese Anbieter die E-Mail-Einladungen und temporären Passwörter verschicken und das Zurücksetzen der Passwörter übernehmen.

Es gibt noch einen letzten Punkt in diesem Onboarding-Flow, den du beachten musst. Bei der Erstellung des Tenants (Schritt 2) habe ich den aktiven Status des Tenants auf false gesetzt. Es ist die Aufgabe deines Onboarding-Dienstes, den Status all dieser verschiedenen Onboarding-Status zu verfolgen. Erst wenn er feststellt, dass jeder Prozess erfolgreich abgeschlossen wurde, setzt er den aktiven Status des Tenants auf true. Dies kann Prozesswiederholungen und andere Fallback-Strategien beinhalten, um Fehler zu beheben, die während der Bereitstellung und Konfiguration der Tenant-Umgebung aufgetreten sein könnten. Wenn das Onboarding erfolgreich war, kann der Onboarding-Dienst nun den Tenant Management-Dienst aufrufen und den aktiven Status auf true setzen. Dies ist besonders wichtig für die Verwaltungskonsole deiner SaaS-Umgebung, die die Funktionen zur Verfügung stellt, mit denen du den Status der Tenants einsehen und verwalten kannst. Während des Onboarding-Prozesses sollte die Ansicht der Mieter den Status jedes Mieters anzeigen, der gerade onboarded wird, und den aktiven Status deiner Mieter hervorheben.

Verfolgen und Aufdecken von Onboarding-Zuständen

Wenn du dir diesen Prozess ansiehst, sollte klar sein, dass dein Onboarding-Prozess viele bewegliche Teile und Abhängigkeiten umfasst. Je komplexer dieser Prozess wird, desto wichtiger ist es, nützliche, detaillierte Einblicke in die verschiedenen Zustände deines Onboarding-Prozesses zu haben. Dies ist wichtig, um den Fortschritt zu analysieren, Probleme zu erkennen und ein Profil des Gesamtverhaltens und der Trends deiner Onboarding-Automatisierung zu erstellen. Das bedeutet auch, dass du das richtige Design und die richtigen Werkzeuge finden musst, um das Onboarding-Profil deiner Lösung effektiv zu erfassen und darzustellen.

Zumindest könntest du dir vorstellen, dass du jedem Schritt in unserem Onboarding-Flow eine eigene Gruppe von Zuständen zuordnest. Du könntest also separate Zustände für TENANT_CRE⁠ATED, TENANT_PROVISIONED, BILLING_INITIALIZED, USER_CREATED und TENANT_ACTIVATED haben. Jeder dieser Zustände könnte über die Tenant-Ansicht in deiner Verwaltungskonsole angezeigt werden, so dass du das Onboarding eines jeden Tenants zu einem bestimmten Zeitpunkt überprüfen kannst.

Der eigentliche Wert der Zuweisung und Anzeige von Onboarding-Status besteht darin, dass du einen besseren Einblick in den Status deines Onboarding-Fortschritts erhältst. Dies ist wichtig, um unerwartete Onboarding-Probleme zu beheben. Für deine Betriebsteams ist es von größter Bedeutung, genau zu wissen, wo dein Onboarding-Prozess fehlschlägt. Das ist besonders wichtig, wenn dein Onboarding-Prozess einen großen Teil der Infrastrukturbereitstellung und -konfiguration umfasst. In diesen Fällen kannst du detailliertere Zustände verfolgen, die dir Einblicke in die verschiedenen Phasen deines Bereitstellungsprozesses geben.

Stufenbasiertes Onboarding

Im Rahmen der Betrachtung des Onboarding-Prozesses habe ich die Rolle des Provisioning-Dienstes und seine Rolle bei der Erstellung und Konfiguration von Tenant-Umgebungen beschrieben. Der Provisioning-Prozess wird noch interessanter, wenn du dir überlegst, wie verschiedene Tenant-Tiers die Umsetzung deines Provisioning-Lebenszyklus beeinflussen können. Wie du dich erinnerst, verwenden wir Tiers, um verschiedenen Tenant-Profilen unterschiedliche Erfahrungen zu bieten. Diese unterschiedlichen Erfahrungen führen oft dazu, dass du je nach Ebene deines Systems unterschiedliche Infrastrukturen und Konfigurationen benötigst.

Um dies besser zu verstehen, schauen wir uns ein konzeptionelles Beispiel für ein tierbasiertes Onboarding-Beispiel an. Abbildung 4-6 zeigt eine Umgebung, die zwei verschiedene Stufen (Basis und Premium) unterstützt.

Ich habe die Ansicht eingegrenzt, um ausschließlich auf den Provisioning-Dienst innerhalb unserer Kontrollebene zu konzentrieren. Wenn der Onboarding-Dienst den Provisioning-Dienst auslöst, stellt er dem Tenant Kontextinformationen zur Verfügung, zu denen auch der Tier gehört, der mit dem neuen Tenant verknüpft werden soll. Wenn der Provisioning-Dienst diese Anfrage erhält, bewertet er die Schicht und legt fest, wie sich die gewählte Schicht auf die Konfiguration und die Infrastruktur auswirkt, die zur Unterstützung deiner Tenant-Umgebung benötigt wird. In diesem Beispiel bietet unsere SaaS-Lösung Premium-Tier-Tenants einen Full-Stack-Silo-Bereitstellungsmodus mit vollständig dedizierten Ressourcen für jeden Tenant. Das bedeutet, dass bei jedem Onboarding-Event die Bereitstellung dieser vollständigen Tenant-Stacks automatisiert werden muss. Basic-Tier-Mieter hingegen werden in ein Full-Stack-Pool-Modell eingebunden, bei dem die gesamte Infrastruktur von den Mietern gemeinsam genutzt wird. Hier ist das Onboarding weniger aufwändig, da die Konfiguration lediglich um die Unterstützung für den neuen Tenant erweitert wird.

Diese Full-Stack Bereitstellungsmodelle haben ziemlich eindeutige Onboarding-Erfahrungen, die relativ leicht zu verdauen sind. Interessant wird es, wenn du ein gemischtes Bereitstellungsmodell hast. Bei einem gemischten Bereitstellungsmodell werden deine Ressourcen getrennt und mit einer feineren Granularität gepoolt. Das bedeutet, dass dein Onboarding-Prozess die tierbasierten Onboarding-Richtlinien auf jede Ressource anwenden muss, je nachdem, ob sie in einem Silo oder Pool untergebracht ist. In Abbildung 4-7 siehst du ein Beispiel dafür, wie die gemischte Bereitstellung deinen Bereitstellungsprozess beeinflusst.

Ich habe diese Architektur absichtlich etwas unübersichtlich gestaltet. Hier ist derselbe Provisioning-Dienst zu sehen, aber jetzt gibt es viel mehr zu beachten, wenn die einzelnen Tenants an Bord kommen. Beginnen wir auf der linken Seite von Abbildung 4-7, wo du siehst, dass ich zwei Dienste habe, die getrennt für Tenant 1 und Tenant 2 eingesetzt werden. Für jeden Premium-Tier-Tenant muss dein Provisioning-Service also die Dienste Fulfillment und Order in einem vollständig isolierten Modell konfigurieren und bereitstellen. Die Speicherung und die Rechenleistung dieser beiden Microservices sind vollständig voneinander getrennt.

Obwohl diese beiden Microservices separat für Premium-Tier-Tenants bereitgestellt werden, werden sie auch von deinen Basic-Tier-Tenants in Anspruch genommen. Dies wird in der Mitte des Diagramms dargestellt, wo ich gepoolte Versionen der Microservices Fulfillment und Order gekennzeichnet habe, die von allen Nicht-Premium-Tier-Tenants (in diesem Fall Tenants 3...N) gemeinsam genutzt werden. Das bedeutet, dass der Provisioning-Dienst diese Dienste einmalig konfigurieren und bereitstellen muss, um die gepoolten Tenants zu unterstützen. Sobald diese Dienste einsatzbereit sind, benötigt der Provisioning Service für jeden neuen Tenant weniger bewegliche Teile. Es kann sein, dass du das Routing konfigurieren oder einige Richtlinien einrichten musst, aber der größte Teil der Arbeit wird nach der ersten Bereitstellung und dem Einsatz dieser Dienste erledigt sein.

Auf der rechten Seite der Umgebung in Abbildung 4-7 schließlich siehst du eine Reihe von Diensten, die in unterschiedlichen Modellen bereitgestellt werden, um die Bedürfnisse der Premium- und Basic-Tier-Mieter zu erfüllen. Die Auswahl der Silos und Pools, die du hier triffst, richtet sich eher nach den allgemeinen Anforderungen deiner Multi-Tenant-Architektur (und nicht nach den Ebenen). Die Idee ist, dass du die Silo- und Pool-Optionen auf der Grundlage einer Reihe von globalen Anforderungen auswählst (laute Nachbarn, Einhaltung von Vorschriften und so weiter).

In diesem Beispiel habe ich absichtlich einige Variationen dieser Dienste erstellt, um die Anwendungsfälle zu verdeutlichen, die du im Rahmen des Tenant Onboarding unterstützen musst. Der Microservice "Produkt" zum Beispiel nutzt für alle Tenants getrennte Rechenleistung; deshalb siehst du für die Tenants 1-3 eine eigene Instanz des Dienstes. Du wirst aber auch sehen, dass dieser Dienst eine gepoolte Speicherung verwendet. Das macht die Sache mit dem Onboarding noch komplizierter. Dein Bereitstellungsdienst muss nun diese Variation handhaben, indem er die Speicherung einmalig für alle Tenants bereitstellt, während er gleichzeitig separate Instanzen des Produkt-Microservice bereitstellt, wenn jeder Tenant onboarded wird.

Die anderen Dienste (Ratings und Cart) sind hier nur , um weitere Muster aufzuzeigen, die du bei der Implementierung deines Provisioning-Dienstes sehen könntest. Bei Ratings werden die Rechenleistung und die Speicherung vollständig gepoolt, während der Microservice Cart eine gepoolte Rechenleistung und eine Silo-Speicherung hat. Bei der Unterstützung des Onboardings für diese Dienste geht es darum, zu wissen, was siloed und was pooled ist, und die Erstellung und Konfiguration dieser Ressourcen kontextabhängig auszulösen. Dies spiegelt die Diskussion wider, die wir (in Kapitel 3) über die Bereitstellung im gemischten Modus geführt haben. Hier schauen wir uns jedoch an, wie dieser gemischte Modus das Onboarding-Erlebnis deiner Multi-Tenant-Umgebung beeinflussen kann.

Eine wichtige Frage, die oft gestellt wird, betrifft den allgemeinen Zeitpunkt der Bereitstellung von gepoolten Ressourcen während des Einführungsprozesses. Da diese Ressourcen nur einmal konfiguriert und bereitgestellt werden, ziehen es viele vor, diese Ressourcen bereits bei der Ersteinrichtung der gesamten mandantenfähigen Umgebung zu provisionieren. Wenn du also eine brandneue Basisumgebung einrichtest, kannst du dich dafür entscheiden, alle gepoolten Ressourcen zu diesem Zeitpunkt bereitzustellen. Das scheint mir der natürlichere Ansatz zu sein. Das könnte bedeuten, dass dein Provisioning Service einen separaten Pfad unterstützt, der von deinen DevOps-Tools aufgerufen wird, um die einmalige Erstellung dieser Ressourcen durchzuführen. Wenn dann ein neuer Tenant an Bord kommt, ist diese gemeinsame Infrastruktur bereits vorhanden.

Die andere Möglichkeit wäre, die Erstellung dieser gepoolten Ressourcen zu verzögern und sie während des Onboardings deines ersten Tenants zu erstellen (fast wie das Lazy Loading Pattern). Das könnte zwar den Onboarding-Prozess verlangsamen, aber der Overhead dieses Prozesses würde nur von deinem ersten Tenant getragen werden. Generell würde ich dazu raten, diese Ressourcen im Voraus bereitzustellen. Es kann aber auch andere Faktoren geben, die dich zu einer der beiden Strategien bewegen.

Es kann zwar interessant und leistungsfähig sein, diese verschiedenen schichtbasierten Bereitstellungsmodelle zu unterstützen, aber es ist auch wichtig zu bedenken, wie sich die Komplexität des Onboardings auf die Komplexität der gesamten SaaS-Umgebung auswirken kann. Ja, du willst dem Unternehmen viele Werkzeuge an die Hand geben, um verschiedene Mieterprofile zu unterstützen. Gleichzeitig willst du aber auch nicht zu sehr rotieren. Außerdem ist es wichtig zu betonen, dass dies immer noch eine Stufe der Anpassung ist. Du solltest diesen Mechanismus nicht als Möglichkeit sehen, eine einmalige Anpassung für einzelne Mieter zu unterstützen.

Verfolgung der eingebrachten Ressourcen

Wenn dein Onboarding-Prozess die Bereitstellung von mandantenspezifischen Ressourcen erfordert, musst du dir auch Gedanken darüber machen, wie deine mandantenfähige Umgebung diese Ressourcen verfolgen und identifizieren kann. Dabei wirst du feststellen, dass andere Aspekte deines Systems diese mieterspezifischen Ressourcen finden und ansprechen müssen.

Um wirklich zu verstehen, worauf ich hinaus will, lass uns ein konkreteres Beispiel betrachten. Stell dir vor, du hast einen Tenant im gemischten Bereitstellungsmodell in Abbildung 4-7 an Bord geholt. Dieses Modell enthält viele Beispiele für siloed und pooled Ressourcen. Stell dir nun vor, du hast einen Premium-Tier-Tenant in diese Umgebung eingebunden und die einzelnen Ressourcen erstellt, die zur Unterstützung dieses Tenants benötigt werden.

Sobald das Onboarding abgeschlossen und unser Tenant betriebsbereit ist, wirst du weiterhin Updates in dieser Umgebung bereitstellen. Patches, neue Funktionen und andere Änderungen müssen im Laufe des Lebenszyklus deiner Anwendung natürlich auch bereitgestellt werden. An dieser Stelle werden die Dinge etwas interessanter. Bei der gemischten Bereitstellung, die wir hier haben, können wir nicht einfach an einem statischen Ort bereitstellen, um unser System zu aktualisieren. Stell dir zum Beispiel vor, du würdest eine neue Version des Bestelldienstes einführen. Um den neuen Code zu implementieren, muss dein DevOps-Team die einzelnen Implementierungen des Bestelldienstes finden, die sich auf alle verschiedenen Ressourcen erstrecken, die beim Onboarding bereitgestellt wurden. In diesem Fall würde das bedeuten, dass der Bestelldienst in den Premium-Tier-Silos von Tenant 1 und Tenant 2 sowie in der gepoolten Instanz des Basic-Tiers, die von den anderen Tenants gemeinsam genutzt wird, bereitgestellt wird.

Das wirft die Frage auf: Woher soll dein Bereitstellungsprozess wissen, wie er damit umgehen soll? Woher soll er wissen, welche Ressourcen für die einzelnen Mandanten in einem Silo sind? Das kann nur funktionieren, wenn dein Onboarding-Prozess den Standort und die Identität dieser Ressourcen für jeden Mandanten erfasst und aufzeichnet. Obwohl der Bedarf an diesen Informationen klar ist, gibt es keine klare oder standardisierte Strategie, um dies zu erreichen. Manche legen die Daten in einer Tabelle ab, wenn neue Mieter an Bord kommen, und beziehen sich während des Bereitstellungsprozesses auf diese Tabelle. Andere nutzen Teile ihrer DevOps-Toolkette, um diese Herausforderung zu meistern. Die wichtigste Erkenntnis ist, dass du, wenn dein Onboarding-Prozess dedizierte Tenant-Ressourcen vorsieht, die Informationen über diese Ressourcen erfassen und aufzeichnen musst, damit sie von anderen Teilen deines Bereitstellungs- und Betriebsprozesses referenziert werden können. Konkrete Beispiele dafür wirst du sehen, wenn wir uns mit der Orchestrierung des Onboarding in EKS(Kapitel 10) und serverlosen(Kapitel 11) Beispielen beschäftigen.

Umgang mit Onboarding-Fehlern

Jeder Fehler im Onboarding-Prozess kann für SaaS-Anbieter ein großes Problem darstellen. In einer Multi-Tenant-Umgebung mit Self-Service-Onboarding sind diese Fehler jedoch noch wichtiger. Das Onboarding ist der erste Eindruck, den du bei einem Mieter hinterlässt, und jeder Fehler in diesem Prozess kann sich in verlorenem Geschäft niederschlagen.

Während ein Teil deiner Zuverlässigkeit aus der Anwendung solider technischer Verfahren resultiert, gibt es auch Bereiche im Onboarding, in denen deine Abhängigkeiten von externen Systemen die Dauerhaftigkeit deines Onboarding-Prozesses beeinflussen können. Um ein besseres Gefühl für die Möglichkeiten zu bekommen, schauen wir uns ein konkretes Beispiel für eine mögliche externe Abhängigkeit an, die Teil deines Onboarding-Prozesses sein könnte. Abbildung 4-8 zeigt eine konzeptionelle Ansicht der Rechnungsintegration, die Teil deines Onboarding-Prozesses sein könnte.

In diesem Beispiel gehen wir davon aus, dass du auf eine Integration mit einem Drittanbieter angewiesen bist. Indem du in dein Onboarding einbeziehst (was üblich ist), machst du die Zuverlässigkeit deines Onboarding-Erlebnisses direkt von der Verfügbarkeit des Rechnungsanbieters abhängig. Fällt das Abrechnungssystem aus, ist auch das Onboarding deines Mieters gestört.

Du könntest jetzt annehmen, dass dies nur das Risiko ist, das mit dem Einsatz von Drittanbieterlösungen verbunden ist. In diesem Szenario ist es jedoch sehr wahrscheinlich, dass dein System weiterläuft, auch wenn das Abrechnungssystem nicht verfügbar ist. Es stimmt zwar, dass du das Abrechnungskonto einrichten musst, aber dein System könnte trotzdem den Onboarding-Prozess abschließen und die Abrechnungskonfiguration vornehmen, wenn das System wieder online ist.

In Abbildung 4-8 habe ich einen möglichen Ansatz zur Lösung dieses Problems aufgezeigt: die Integration der Abrechnung muss vollständig asynchron erfolgen. In diesem Modell würde dein Onboarding-Prozess das Hinzufügen eines neuen Mieters über in einer Warteschlange anfordern. Der Abrechnungsdienst nimmt die Anfrage entgegen und versucht, mit einer asynchronen Anfrage ein Konto im Abrechnungssystem zu erstellen. Wenn diese Anfrage fehlschlägt, erfasst der Billing-Dienst den Fehler und plant einen neuen Versuch. Es gibt viele verschiedene Strategien, um eine fehlertolerante Integration zu implementieren. Verliere dich nicht in den Details. Das Wichtigste ist, dass ich ein Integrationsmodell mit dem Abrechnungsdienstleister entwickelt habe, das es mir ermöglicht, meinen Onboarding-Prozess fortzusetzen, ohne auf die Erstellung des Abrechnungskontos zu warten. Für manche ist es vielleicht besser, wenn es sich um eine asynchrone Integration handelt, nur um den Onboarding-Prozess zu beschleunigen.

Ich habe mich auf die Rechnungsstellung konzentriert, weil sie ein natürliches Beispiel dafür ist, wie wichtig ein fehlertolerantes Onboarding-Erlebnis ist. In Wirklichkeit solltest du dir alle beweglichen Teile deiner Onboarding-Automatisierung ansehen und nach Fehlerpunkten oder Engpässen suchen, die neue Strategien erfordern, die deinen Onboarding-Prozess beschleunigen oder haltbarer machen. Die Kosten für ein fehlgeschlagenes Onboarding sind in der Regel hoch und du solltest alles tun, um diesen Mechanismus so robust wie möglich zu machen.

Teste dein Onboarding-Erlebnis

An dieser Stelle sollte die Rolle und Bedeutung des Onboarding klar sein. Die potenzielle Komplexität und die Anzahl der beweglichen Teile in diesem Prozess können ihn besonders fehleranfällig machen. Aus diesem Grund solltest du zusätzliche Maßnahmen ergreifen, um die Effizienz und Wiederholbarkeit deines Onboarding-Prozesses zu überprüfen. Zu viele Teams erstellen einen Onboarding-Prozess und verlassen sich einfach auf die Aktivität der Kunden, um Engpässe oder Designfehler aufzudecken, die sich auf das Onboarding-Erlebnis auswirken könnten. Um dies zu vermeiden, schlage ich vor, dass Teams in den Aufbau einer umfangreichen Sammlung von Onboarding-Tests investieren, mit denen sie alle Dimensionen des Onboarding-Erlebnisses trainieren und überprüfen können.

Hier gibt es eine Reihe möglicher Testarten, die du in Betracht ziehen kannst. Du könntest z. B. Lasttests für das Onboarding erstellen, die verschiedene Arbeitslasten simulieren. Oder du könntest Tests erstellen, die deine Fähigkeit zur Wiederherstellung nach Fehlern überprüfen. Manche Teams führen Leistungstests ein, die die Zeit messen, die für das Onboarding von Mietern benötigt wird. Jeder dieser Tests könnte mit einer Mischung aus verschiedenen Tenant-Tiers durchgeführt werden, wobei ein Tenant-Tier verschiedene Pfade deines Onboarding-Erlebnisses ausprobieren könnte.

Das Ziel ist es, sicherzustellen, dass das Design, die Architektur und die Automatisierungsannahmen deines Onboarding-Erlebnisses in deiner Arbeitslösung vollständig umgesetzt werden. Das bedeutet, dass du die Skalierung vorantreibst, indem du eine ganze Reihe von Anwendungsfällen simulierst, die dein Onboarding-Design und deine Implementierung vorantreiben. So kannst du auch überprüfen, ob deine Umgebung alle wichtigen Kennzahlen, mit denen du die Einhaltung der von dir festgelegten SLAs messen kannst, korrekt wiedergibt. Dabei geht es nicht nur darum, sicherzustellen, dass der "Happy Path" funktioniert, sondern auch darum, dass das Onboarding die Skalierungs- und Verfügbarkeitsanforderungen erfüllt und ein Serviceerlebnis bietet, das die Erwartungen deiner Kunden erfüllt.

Eine SaaS-Identität schaffen

Bisher habe ich die Rolle der Identität als Teil des Onboarding-Prozesses kurz gestreift. Es gibt jedoch noch viele weitere Teile des Identitätspuzzles, die untersucht werden müssen. Ja, beim Onboarding wird die Identität eingerichtet, aber was bedeutet das? Wie wird die Identität konfiguriert und wie wirkt sich die Mandantenfähigkeit auf das Gesamterlebnis in unserer SaaS-Umgebung aus? Hier werden wir uns genauer ansehen, wie die Mandantenfähigkeit die Authentifizierung, Autorisierung und den allgemeinen Multi-Tenant-Fußabdruck einer SaaS-Umgebung beeinflusst.

Mit der Multi-Tenant-Identität musst du nicht mehr nur als Werkzeug zur Authentifizierung von Nutzern betrachten. Du musst deinen Blick auf die Identität erweitern und berücksichtigen, dass jeder authentifizierte Nutzer immer im Kontext eines Mandanten authentifiziert werden muss. Es stimmt zwar, dass die Nutzer mit dieser Erfahrung verbunden sind, aber ein Großteil der zugrunde liegenden Implementierung deiner Multi-Tenant-Architektur konzentriert sich in erster Linie auf den mit dem Nutzer verbundenen Tenant. Das bedeutet, dass unser Identitätsmodell so erweitert werden muss, dass es sowohl die Nutzer als auch die Tenants abdeckt. Das grundlegende Ziel ist es, eine engere Verbindung zwischen Nutzern und Tenants zu schaffen, die es ermöglicht, auf sie zuzugreifen, sie gemeinsam zu nutzen und sie als eine Einheit zu verwalten.

In Abbildung 4-9 siehst du eine konzeptionelle Ansicht, wie eine SaaS-Identität aufgebaut ist. Auf der linken Seite ist die klassische Ansicht einer Benutzeridentität zu sehen, die ich als bezeichne. Diese Identität konzentriert sich ganz auf die Beschreibung und Erfassung der Eigenschaften einer Person. Name, Telefonnummer, E-Mail - das sind alles typische Merkmale, mit denen der Nutzer eines Systems beschrieben werden kann. Auf der rechten Seite habe ich jedoch auch die Idee einer Mieteridentität eingeführt. Ein Tenant ist eher eine Einheit als eine Einzelperson. Ein Unternehmen zum Beispiel abonniert deinen SaaS-Dienst als Tenant, und dieser Tenant hat oft viele Nutzer.

In mandantenfähigen Umgebungen werden diese beiden unterschiedlichen Identitätskonzepte zu einer so genannten SaaS-Identität zusammengeführt. Diese SaaS-Identität muss so eingeführt werden, dass sie zu einem erstklassigen Identitätskonstrukt wird, das durch alle Schichten deines Systems geleitet wird. Sie wird zum Vehikel, um den Kontext deines Mandanten an alle Teile deines Systems zu übermitteln, die Zugriff auf diese Benutzer- und Mandantenattribute benötigen. Diese SaaS-Identität lässt sich direkt auf das in Kapitel 1 beschriebene Tenant-Kontext-Konzept übertragen.

Entscheidend ist, dass diese SaaS-Identität eingeführt werden muss, ohne die herkömmliche Authentifizierung zu beeinträchtigen oder zu verkomplizieren. Dein SaaS-Authentifizierungssystem muss die Freiheit haben, einem klassischen Authentifizierungsablauf zu folgen, und gleichzeitig die Verschmelzung von Nutzer- und Mieteridentitäten ermöglichen. Abbildung 4-10 veranschaulicht dieses Konzept in der Praxis.

In dem Ablauf, den du hier siehst, versucht ein Tenant-Nutzer, auf eine SaaS-Webanwendung zuzugreifen (Schritt 1). Die Anwendung stellt fest, dass der Nutzer nicht authentifiziert ist und leitet ihn an einen Identitätsanbieter weiter, der sowohl die Nutzer- als auch die Mandantenidentität kennt (Schritt 2). Wenn der Nutzer authentifiziert ist, ist der Identitätsanbieter für die Rückgabe der SaaS-Identität verantwortlich (Schritt 3). Dann wird diese SaaS-Identität an alle anderen beweglichen Teile unseres Systems weitergegeben (Schritt 4). Diese Identität enthält alle Mieter- und Benutzerattribute, die für die übrigen Elemente deiner SaaS-Anwendung benötigt werden.

Auch wenn dieser Ablauf je nach Art deiner Identitätstechnologie variieren kann, sollte der Grundgedanke dieses Erlebnisses bei verschiedenen Identitätsmodellen ähnlich sein. Es kann auch davon abhängen, wie die Kunden in dein System kommen und zu einem Identitätsanbieter weitergeleitet werden. Subdomänen, E-Mail-Adressen oder Nachschlagetabellen können z. B. beeinflussen, wie du den Weg eines Kunden zum entsprechenden Identitätsanbieter auflöst. Letztendlich ist es dein Ziel, die SaaS-Identität am Anfang des Prozesses aufzulösen und zu erstellen und zu vermeiden, dass du diese Verantwortung weiter in die Details deines Designs und deiner Implementierung verschiebst.

Anbringen einer Mieteridentität

In diesem Abschnitt habe ich über die Verbindung von Benutzer- und Mieteridentitäten gesprochen. Auch wenn das konzeptionell sinnvoll ist, haben wir noch nicht darüber gesprochen, wie du diese beiden Konzepte zu einem echten, erstklassigen SaaS-Identitätskonstrukt kombinieren kannst. Wie du das machst, ist natürlich von einem Identitätsanbieter zum anderen verschieden.

In dieser Diskussion werde ich mich darauf konzentrieren, wie die Open Authorization (OAuth) und OpenID Connect (OIDC) Spezifikationen zur Erstellung und Konfiguration einer SaaS-Identität verwendet werden können. Diese Spezifikationen werden von vielen modernen Identitätsanbietern verwendet und dienen als offener Standard für die dezentrale Authentifizierung und Autorisierung. Du solltest also feststellen, dass sich die hier vorgestellten Techniken ganz natürlich auf das Identitätsmodell deiner Anwendung übertragen lassen.

Um den Nutzern Mieter zuzuordnen, müssen wir zunächst verstehen, wie die OIDC-Spezifikation die Authentifizierungsinformationen eines Nutzers verpackt und übermittelt. Wenn du dich bei einem OIDC-kompatiblen Identitätsanbieter authentifizierst, werden bei jeder Authentifizierung Identitäts- und Zugriffstoken zurückgegeben. Diese werden als JSON-Web-Token (JWTs) dargestellt, die den gesamten Authentifizierungskontext enthalten, der für die nachfolgende Autorisierung verwendet wird. Das Identitäts-Token dient dazu, Informationen über einen Nutzer zu übermitteln, während das Zugriffs-Token verwendet wird, um den Zugriff des Nutzers auf verschiedene Ressourcen zu autorisieren .

In diesen JWTs findest du eine Reihe von Eigenschaften und Werten, die detailliertere Informationen über einen Nutzer liefern. Diese Daten werden als Claims bezeichnet. Es gibt einen Standardsatz von Angaben, die in der Regel mit jedem Token mitgeliefert werden, um eine standardisierte Darstellung gemeinsamer Attribute zu gewährleisten. Diese JWTs sind die universelle Währung unseres Multi-Tenant-Identitätsmodells.

Die gute Nachricht bei JWTs ist, dass sie die Einführung von benutzerdefinierten Ansprüchen ermöglichen. Diese benutzerdefinierten Claims sind im Wesentlichen das Äquivalent zu benutzerdefinierten Feldern, mit denen du deine eigenen Eigenschaften/Wertpaare an JWTs anhängen kannst. Dadurch hast du die Möglichkeit, kontextbezogene Daten an diese Token anzuhängen. Abbildung 4-11 veranschaulicht, wie diese benutzerdefinierten Claims zu deinen JWTs hinzugefügt werden können .

Auf der linken Seite ist ein JWT-Beispiel zu sehen, das mit den in der OIDC-Spezifikation enthaltenen Angaben gefüllt ist. Ich werde sie nicht alle aufzählen, aber es lohnt sich, die spezifischen Benutzerattribute zu nennen, die hier auftauchen. Du wirst sehen, dass name, given_name, family_name, gender, birthdate und email alle in dieser Liste enthalten sind. Auf der rechten Seite befinden sich die Attribute unseres Mieters, die in das JWT integriert werden müssen. Diese werden einfach als Eigenschaft/Wert-Paare zur standardisierten Darstellung hinzugefügt.

Dieses Modell hat zwar nichts Magisches oder Elegantes an sich, aber die Möglichkeit, diese benutzerdefinierten Ansprüche als Bürger erster Klasse einzuführen, bietet einen erheblichen Vorteil. Stell dir vor, wie sich die Einbettung dieser Attribute als Ansprüche auf die Authentifizierung und Autorisierung in deinem Multi-Tenant-System auswirkt. Abbildung 4-12 zeigt, wie sich dieses scheinbar einfache Konstrukt kaskadenartig auf die gesamte mandantenfähige Architektur auswirkt.

In diesem Beispiel beginnt der Ablauf bei der Webanwendung. Der Nutzer ruft diese Seite auf und wird nicht authentifiziert, was ihn zur Authentifizierung an den Identitätsanbieter weiterleitet (Schritt 1). Das ist ein sehr vertrauter und einfacher Ablauf, den du wahrscheinlich schon oft gemacht hast. Der Unterschied ist, dass die Daten von dieser Authentifizierung zurückkommen. Wenn du dich hier authentifizierst, gibt der Identitätsanbieter seine Standard-Tokens zurück (Schritt 2). Da ich den Identitätsprovider jedoch mit mieterspezifischen Ansprüchen konfiguriert habe, stimmen die zurückgegebenen Token mit der SaaS-Identität überein, über die wir bereits gesprochen haben. Die Token nehmen teil und verhalten sich wie jedes andere Token, sind aber mit dem zusätzlichen Tenant-Kontext angereichert, den wir für die Erstellung einer SaaS-Identität benötigen.

Jetzt können diese Token als Inhaber-Token injiziert und an deine Backend-Dienste weitergegeben werden, wobei sie alle Sicherheits-, Lebenszyklus- und anderen Mechanismen übernehmen, die in den OIDC- und OAuth-Spezifikationen enthalten sind (Schritt 3). Diese Strategie ist besonders wirkungsvoll, wenn du dir ansiehst, wie sie sich auf die allgemeine Erfahrung deiner Backend-Dienste auswirkt. Abbildung 4-13 zeigt ein Beispiel dafür, wie diese Token durch die verschiedenen Multi-Tenant-Microservices deiner Anwendung fließen könnten.

Ich habe drei verschiedene Microservices, von denen jeder Zugriff auf den Tenant-Kontext benötigt. Wenn du dich authentifizierst und ein Tenant-Aware-Token erhältst, wird dieses Token an den Microservice weitergegeben, den du zuerst aufrufst. In diesem Fall geht der Aufruf an den Microservice Order (Schritt 1). Stell dir dann vor, dass dieser Dienst einen anderen Backend-Dienst (Product) aufrufen muss, um seine Aufgabe zu erfüllen. Dann kann er das gleiche Token an den Produktdienst weitergeben (Schritt 2). Dieses Muster kann dann kaskadenförmig durch weitere nachgelagerte Dienstaufrufe weitergegeben werden (Schritt 3). In diesem Beispiel bin ich davon ausgegangen, dass ich das JWT als Überbringer-Token in eine HTTP-Anfrage einfügen kann. Aber auch wenn du ein anderes Protokoll verwendest, gibt es wahrscheinlich Möglichkeiten, dieses JWT als Teil deines Kontexts einzufügen.

Du kannst dir vorstellen, wie dieser sehr einfache Mechanismus am Ende einen ziemlich tiefgreifenden Einfluss auf deine gesamte mandantenfähige Architektur hat. Ein einziges JWT berührt so viele der beweglichen Teile innerhalb der Implementierung deiner mandantenfähigen Umgebung. Microservices nutzen es für Logging, Metriken, Abrechnung, Tenant-Isolierung, Datenpartitionierung und eine Vielzahl anderer Bereiche. Deine breitere SaaS-Architektur wird sie für Tiering, Throttling, Routing und andere globale Mechanismen nutzen, die einen Tenant-Kontext erfordern. Es ist zwar ein einfaches Konzept, aber die Bedeutung seiner Rolle innerhalb deiner SaaS-Architektur kann nicht unterschätzt werden.

Benutzerdefinierte Ansprüche beim Onboarding eingeben

Wir haben jetzt gesehen, wie wir mit benutzerdefinierten Ansprüchen Nutzer mit Mietern verbinden können. Was vielleicht weniger klar ist, ist, wie und wann diese Ansprüche tatsächlich eingeführt werden. Es gibt zwei ziemlich einfache Schritte , die mit dem Hinzufügen und Auffüllen dieser benutzerdefinierten Ansprüche verbunden sind. Zunächst musst du deinen Identitätsanbieter konfigurieren, bevor du einen Tenant einbinden kannst, und alle benutzerdefinierten Attribute festlegen, die du zu deiner Authentifizierung hinzufügen möchtest. Hier legst du alle Eigenschaften und Typen fest, die in deinen benutzerdefinierten Angaben enthalten sein sollen. So wird dein Identity Provider darauf vorbereitet, neue Tenants zu akzeptieren, die ihre Tenants mit den zusätzlichen Attributen speichern und konfigurieren können.

Die zweite Hälfte dieses Prozesses wird beim Onboarding durchgeführt. Vorhin habe ich die Erstellung des Benutzers für die Mieterverwaltung als Teil des gesamten Onboarding-Prozesses beschrieben. Was ich jedoch nicht erwähnt habe, war die Erstellung der benutzerdefinierten Ansprüche für deinen neu angelegten Mieter. Wenn du die Informationen zu deinem Nutzer (Name, E-Mail usw.) hinzufügst, füllst du auch alle Tenant-Kontextfelder für diesen Nutzer aus (Tenant-ID, Rolle, Stufe). Diese Daten müssen für jeden Nutzer innerhalb des Identitätsproviders eingegeben werden. Auch nach dem Onboarding müssen also bei der Einführung weiterer Nutzer diese benutzerdefinierten Attribute eingegeben werden.

Sorgfältige Verwendung von Zollansprüchen

Benutzerdefinierte Ansprüche sind ein nützliches Konstrukt, um deinen Token einen Tenant-Kontext zuzuordnen. In einigen Fällen schließen sich Teams diesem Mechanismus an und erweitern seine Rolle, indem sie ihn nutzen, um den Sicherheitskontext der Anwendung zu erfassen und zu vermitteln. Auch wenn es hier keine festen Regeln gibt, gehe ich in der Regel davon aus, dass ein benutzerdefinierter Claim eine wichtige Rolle bei der Gestaltung des Tenant-Kontextes spielt und deine globale Autorisierungsgeschichte beeinflusst.

Viele Anwendungen verlassen sich auf Zugriffskontrollen, um den Zugriff auf bestimmte Anwendungsfunktionen zu aktivieren oder zu deaktivieren. Diese Kontrollen sollten außerhalb des Bereichs deines Identitätsanbieters verwaltet werden. Generell halte ich es für einen Fehler, deine Token mit benutzerdefinierten Ansprüchen aufzublähen, die Teil deiner traditionellen Strategie für die Zugriffskontrolle von Anwendungen sind. Stattdessen sollte diese Art von Kontrolle mit einem der Sprach- oder Technologie-Stack-Mechanismen implementiert werden, die ausschließlich für diesen Zweck entwickelt wurden.

Es kann vorkommen, dass nicht klar ist, ob ein Attribut in einen benutzerdefinierten Anspruch oder in das Zugriffskontrollmodell deiner Anwendung gehört. Meiner Meinung nach wird dies oft anhand des Lebenszyklus und der Rolle des Attributs geklärt. Wenn sich das Attribut mit der Einführung von Anwendungsfeatures, Funktionen und Fähigkeiten weiterentwickelt, sollte es eher über die Zugriffskontrollen der Anwendung verwaltet werden. Im Allgemeinen ist es unwahrscheinlich, dass sich Attribute, die in deinen benutzerdefinierten Ansprüchen landen, ändern, wenn sich deine Anwendung ändert. Der Inhalt deiner Token sollte sich zum Beispiel nicht wöchentlich ändern, wenn neue Anwendungsfunktionen oder Konfigurationsoptionen hinzukommen.

Keine zentralen Dienste für die Lösung des Mieterkontextes

Einige Teams versuchen, eine härtere Grenze zwischen Mieteridentität und Benutzeridentität zu ziehen. In diesen Umgebungen wird der Identitätsanbieter nur zur Authentifizierung von Nutzern verwendet. Die Token, die bei der Authentifizierung eines Nutzers zurückgegeben werden, enthalten keine Kontextinformationen über den Mieter. In diesem Modell müssen sich diese Systeme auf nachgelagerte Mechanismen verlassen, um die Mieterschaft aufzulösen. Abbildung 4-14 zeigt ein Beispiel, wie dies umgesetzt werden könnte.

In diesem Beispiel authentifiziert sich die Webanwendung gegenüber einem Identitätsanbieter, der den Kontext des Mandanten nicht kennt (Schritt 1). Bei einer erfolgreichen Authentifizierung werden immer noch die besprochenen JWTs zurückgegeben. Diese Token enthalten jedoch keine der mandantenspezifischen Claims, die zuvor beschrieben wurden (Schritt 2). Stattdessen sind die einzigen Daten hier die Nutzerdaten. Dieses Token wird dann an den Bestell-Microservice weitergegeben (Schritt 3). Wenn dieser Bestelldienst nun auf die Daten eines bestimmten Tenants zugreifen muss, muss er feststellen, welcher Tenant mit der aktuellen Anfrage verbunden ist. Da das JWT diese Information nicht enthält, muss dein Code den Kontext von einem anderen Dienst beziehen (Schritt 4). In diesem Beispiel habe ich einen Tenant Mapping Service eingeführt, der das JWT entgegennimmt, die Benutzerinformationen extrahiert, den Benutzer zu einem Tenant auflöst und die Kennung des Tenants zurückgibt (Schritt 5). Diese Kennung wird dann verwendet, um eine Bestellung für diesen bestimmten Mieter zu erhalten (Schritt 6).

Oberflächlich betrachtet mag das wie eine absolut gültige Strategie erscheinen. Tatsächlich stellt sie aber viele SaaS-Umgebungen vor echte Herausforderungen. Das kleinere Problem dabei ist, dass es eine harte Trennung zwischen dem Nutzer und dem Tenant gibt und die Teams den gekoppelten Status von Nutzer und Tenant unabhängig voneinander verwalten müssen. Das größere Problem ist jedoch, dass jeder Dienst im System diesen zentralisierten Zuordnungsmechanismus durchlaufen muss, um den Tenant-Kontext aufzulösen. Stell dir vor, dass dieser Schritt für Hunderte von Diensten und Tausende von Anfragen durchgeführt werden muss. Viele, die sich für diesen Ansatz entscheiden, stellen schnell fest, dass dieser Tenant Mapping Service einen erheblichen Engpass in ihrem System verursacht, der dazu führt, dass die Teams versuchen, einen Service zu optimieren, der eigentlich keinen Geschäftswert bietet.

Das ist ein weiterer Grund, warum es so wichtig ist, dass die Benutzer- und Mandantenkontexte miteinander verbunden sind und über die gesamte Oberfläche deiner mandantenfähigen Architektur hinweg gemeinsam genutzt werden. Als Faustregel kann ich sagen, dass ein Dienst niemals einen externen Mechanismus aufrufen muss, um den Tenant-Kontext zu ermitteln und zu erhalten. Du möchtest, dass fast alles, was du über den Tenant wissen musst, über das JWT geteilt wird, das deine SaaS-Identitätsinformationen enthält. Ja, es mag Ausnahmen geben, aber das sollte die generelle Denkweise sein, wenn du darüber nachdenkst, wie du Nutzerinnen und Nutzer den Tenants zuordnest.

Föderierte SaaS-Identität

Das meiste von dem, was ich bisher beschrieben habe, geht davon aus, dass dein SaaS-System mit einem einzigen Identitätsanbieter betrieben werden kann, der unter deiner Kontrolle steht. Dies ist zwar das ideale Szenario und maximiert deine Möglichkeiten, aber es ist auch nicht praktikabel, davon auszugehen, dass jede SaaS-Lösung nach diesem Modell aufgebaut ist. Einige SaaS-Anbieter haben geschäftliche, domänenspezifische oder kundenbezogene Anforderungen, die es erforderlich machen, dass sie einen Kunden oder einen von einem Drittanbieter gehosteten Identitätsanbieter unterstützen.

Ein häufiger Fall, den ich kenne, ist ein Szenario, in dem ein SaaS-Kunde von einem bestehenden internen Identitätsanbieter abhängig ist. Einige dieser Kunden können als Bedingung für ihren Kauf verlangen, dass der SaaS-Anbieter die Authentifizierung über diesen internen Identitätsanbieter unterstützt. In diesen Fällen geht es oft darum, den Wert der Kundenakquise gegen die zusätzliche Komplexität deiner Umgebung abzuwägen, die die Agilität und betriebliche Effizienz deines SaaS-Angebots insgesamt beeinträchtigen könnte. Wenn sich jedoch die richtige Gelegenheit bietet, können die Geschäftsparameter die Teams zu Strategien drängen, die es ihnen ermöglichen, dieses Modell zu unterstützen.

In der Regel wird dies durch eine zusätzliche Ebene der Mandantenkonfiguration erreicht, bei der dein Tenant Onboarding zusätzliche Unterstützung für die Konfiguration des extern gehosteten Identitätsanbieters bietet. Das Ziel ist es, dies so nahtlos wie möglich zu gestalten und die Einführung von invasivem oder einmaligem Code zu begrenzen, der eine mandantenspezifische Anpassung beinhaltet. Die andere Herausforderung besteht darin, dass du in einigen Fällen den externen und den internen Identitätsanbieter nebeneinander unterstützen musst. Die meisten deiner Kunden erwarten wahrscheinlich, dass deine Lösung eine integrierte Identitätsunterstützung bietet. Abbildung 4-15 gibt einen Überblick über die verschiedenen Komponenten dieses Identitätsmusters.

In der Mitte dieses Beispiels siehst du, dass ich einen Authentifizierungsmanager habe. Dies ist ein konzeptioneller Platzhalter für die Einführung eines Dienstes in deinen Authentifizierungsfluss, der eine größere Anzahl von Identitätsanbietern unterstützen kann. Damit dies funktioniert, muss dein System immer bestimmen, wie ein Identitätsanbieter gehostet wird. Jedes Mal, wenn sich ein Nutzer authentifizieren muss, musst du ihn untersuchen und die Identitätskonfiguration abrufen, die Daten enthält, die den Standort und die Konfiguration eines bestimmten Tenants beschreiben.

Auf der linken Seite von Abbildung 4-15 habe ich eine Mischung aus intern und extern gehosteten Identitätsanbietern dargestellt, die von einer einzigen SaaS-Lösung unterstützt werden müssen. Zwei Kunden nutzen ihren eigenen Identitätsanbieter. Die übrigen Mieter nutzen deinen intern gehosteten Identitätsanbieter.

Dieses Modell scheint ziemlich einfach zu sein. Der Haken an der Sache ist jedoch, dass dein System keine Kontrolle über diese externen Identitätsanbieter hat. Du kannst also die Ansprüche dieser Anbieter nicht konfigurieren und auch nicht dafür sorgen, dass dein Onboarding-Prozess den Identitätsdaten, die von diesen Anbietern verwaltet werden, zusätzlichen Mandantenkontext hinzufügt. Das bedeutet, dass die JWTs, die von deinen Authentifizierungsanfragen zurückgegeben werden, keinen Tenant-Kontext enthalten, der für deine Multi-Tenant-Umgebung wichtig ist. Um dieses Problem zu lösen, muss deine Lösung neue Funktionen einführen, die die von diesen externen Identitätsanbietern zurückgegebenen Token anreichern und die Verantwortung für die Anreicherung dieser Token mit dem in deiner SaaS-Umgebung verwalteten Mandantenkontext übernehmen. So können sich alle nachgelagerten Dienste weiterhin auf tenant-aware JWT-Tokens verlassen, unabhängig davon, welcher Identitätsanbieter für die Authentifizierung deines Nutzers verwendet wurde. Wie diese Token angereichert werden, hängt von der Art unserer Lösung ab. Es gibt Strategien, die Hooks bereitstellen, mit denen du den zusätzlichen Tenant-Kontext dynamisch einfügen kannst. In anderen Fällen brauchst du vielleicht eine individuellere Lösung. Generell bieten die Föderationsmodelle des Identitätsraums jedoch oft verschiedene Techniken für diesen Anwendungsfall.

Ich habe dieses Modell aufgenommen, weil es ein unvermeidliches Muster darstellt, das in der freien Wildbahn auftritt. Allerdings hat dieser Ansatz auch klare Nachteile. Jedes Mal, wenn du dich in den Authentifizierungsprozess einschalten musst, übernimmst du eine zusätzliche Rolle in der Sicherheitsstruktur deiner mandantenfähigen Architektur. Wenn du dich in den Authentifizierungsprozess einschaltest, musst du möglicherweise auch die Anforderungen an die Skalierung und den Single Point of Failure erfüllen. Das mag zwar notwendig sein, aber es bringt auch einige Probleme mit sich, die du sorgfältig abwägen solltest .

Mietergruppierung/Mapping-Konstrukte

Während sich Identitätsanbieter oft an etablierte Spezifikationen halten (OIDC, OAuth2), können die Konstrukte, die zur Organisation und Verwaltung von Identitäten verwendet werden, von einem Identitätsanbieter zum nächsten variieren. Diese Anbieter bieten eine Reihe verschiedener Konstrukte an, um Nutzer zu gruppieren und zu organisieren. Dies ist besonders in mandantenfähigen Umgebungen wichtig, in denen du alle Nutzer, die zu einem Mandanten gehören, zusammenfassen möchtest. Diese Gruppenkonstrukte können Auswirkungen darauf haben, wie du Tenants innerhalb deines Identitätsanbieters anlegst. In manchen Fällen kannst du diese Gruppen auch dazu verwenden, um die Authentifizierung und Autorisierung von Tenants nach bestimmten Richtlinien zu gestalten.

Wenn wir uns zum Beispiel Amazon Cognito ansehen, wirst du sehen, dass es mehrere Möglichkeiten bietet, tenants zu organisieren. Cognito führt die Idee des User Pools ein. Diese Benutzerpools werden verwendet, um eine Sammlung von Benutzern zu speichern, und sie können individuell konfiguriert werden, so dass die Pools unterschiedliche Authentifizierungsmöglichkeiten bieten. Dies könnte zu einem User Pool pro Tenant-Modell führen, bei dem jeder Tenant seinen eigenen Pool erhält. Die Alternative wäre, alle Tenants in einem einzigen Benutzerpool zusammenzufassen und andere Mechanismen (z. B. Gruppen) zu verwenden, um Benutzer mit Tenants zu verknüpfen. Du solltest auch bedenken, wie die Beschränkungen deines Identitätsanbieters in die Wahl deiner Strategie einfließen könnten.

Es gibt Kompromisse, die du bei der Wahl zwischen diesen verschiedenen Identitätskonstrukten in Betracht ziehen solltest. So kann es zum Beispiel aufgrund der Anzahl deiner Tenants unpraktisch sein, für jeden Tenant einen eigenen Benutzerpool einzurichten. Oder du brauchst keine großen Unterschiede zwischen den Tenants und ziehst es vor, dass alle Tenants gemeinsam konfiguriert und verwaltet werden. Du solltest dir auch Gedanken darüber machen, wie sich deine Entscheidungen auf den Authentifizierungsfluss deiner SaaS-Lösung auswirken könnten. Wenn du für jeden Tenant eigene Benutzerpools hast, musst du dir überlegen, wie du die Tenants während des Authentifizierungsprozesses den jeweiligen Pools zuordnest. Dies kann zu einer zusätzlichen Ebene der Umleitung führen, die du vielleicht nicht als Teil deiner Lösung akzeptieren willst.

Der Umfang, die Identitätsanforderungen und eine Reihe anderer Überlegungen bestimmen, wie du deine Mandanten den von deinem Identitätsanbieter unterstützten Konstrukten zuordnen kannst. Das Wichtigste ist, dass du bei der Ausarbeitung deiner SaaS-Identitätsstrategie die verschiedenen Organisationseinheiten identifizierst, die zur Gruppierung deiner Mandanten verwendet werden können, und festlegst, wie diese den Umfang, die Authentifizierung und die Konfiguration deiner mandantenfähigen Authentifizierung beeinflussen.

Mit den unterschiedlichen Organisationsstrukturen kommen auch unterschiedliche Optionen für die Identitätskonfiguration. Identitätsanbieter bieten in der Regel eine Reihe von Optionen an, mit denen du deine Authentifizierungserfahrung konfigurieren kannst. Die Multi-Faktor-Authentifizierung (MFA) wird zum Beispiel als Identitätsfunktion angeboten, die aktiviert oder deaktiviert werden kann. Du kannst auch die Anforderungen an die Formatierung von Passwörtern und die Ablaufrichtlinien konfigurieren.

Die Einstellungen für diese verschiedenen Konfigurationsoptionen müssen nicht global auf alle deine Tenants angewendet werden. Vielleicht möchtest du unterschiedliche Identitätsfunktionen für verschiedene Tenant-Tiers zur Verfügung stellen. Vielleicht stellst du MFA nur deinen Premium Tenants zur Verfügung, oder du entscheidest dich, diese Konfigurationsoptionen in der Tenant-Verwaltung deiner SaaS-Anwendung anzuzeigen und jedem Tenant die Möglichkeit zu geben, diese verschiedenen Identitätseinstellungen zu konfigurieren. Dies kann ein Unterscheidungsmerkmal sein, das deinen Kunden einen Mehrwert bietet und ihnen die Möglichkeit gibt, die Identitätseinstellungen so zu gestalten, dass sie den Anforderungen ihres Unternehmens am besten entsprechen.

Wie oder ob du diese Identitätsanpassung anbieten kannst, hängt davon ab, wie dein spezieller Identitätsanbieter diese Optionen organisiert und gestaltet. Bei einigen Providern kannst du diese Optionen für einzelne Tenants separat konfigurieren, bei anderen wiederum nur global. Du musst dich mit den Konstrukten deines Identitätsanbieters auseinandersetzen, um herauszufinden, ob du diese Identitätsrichtlinien mit einzelnen Tenants verknüpfen kannst.

Gemeinsame Nutzung von Benutzer-IDs durch verschiedene Mieter

Jeder Nutzer deines SaaS-Systems hat eine Nutzerkennung, die ihn gegenüber einem Mandanten identifiziert. Diese Benutzerkennung wird oft durch eine E-Mail-Adresse dargestellt. In vielen Fällen wird ein einziger Benutzer mit einem einzigen SaaS-Tenant verbunden. Es gibt jedoch Fälle, in denen SaaS-Anbieter daran interessiert sind, eine einzige E-Mail-Adresse mit mehreren Mandanten zu verknüpfen. Dadurch wird deine Authentifizierung natürlich um eine weitere Ebene erweitert. Irgendwo in deinem Anmeldefluss muss dein SaaS-System feststellen, auf welchen Tenant du zugreifst.

Obwohl ich Anfragen zur Unterstützung dieses Modus gesehen habe, konnte ich noch keine fertige Strategie für diesen Anwendungsfall entdecken. Dennoch gibt es einige Muster, die ich hier gesehen habe. Die brachialste Methode, die ich gesehen habe, ist eine, die die Auflösung des Tenants an den Endnutzer weitergibt: Bei der Anmeldung erkennt das System, dass ein Nutzer zu mehreren Tenants gehört und fordert ihn auf, einen Ziel-Tenant auszuwählen. Das ist alles andere als elegant und führt zu einem Informationsleck, da jeder anhand der E-Mail-Adresse herausfinden kann, zu welchen Mietern du gehörst (falls du zu mehr als einem gehörst). Im Modell würdest du eine Zuordnungstabelle haben, die die Benutzer mit den Tenants verbindet, und du würdest diese als Nachschlagewerk verwenden, bevor du den Authentifizierungsfluss startest.

Ein sauberer Ansatz wäre es, sich auf eine Authentifizierung zu verlassen, die den Kontext expliziter liefert. Das beste Beispiel sind wahrscheinlich Domains und Subdomains. Wenn jedem deiner Tenants eine Subdomain zugewiesen ist(tenant1.saasprovider.com), kann dein Authentifizierungsprozess diese Subdomain nutzen, um den Tenant-Kontext zu erhalten. Dann würde das System dich gegenüber dem angegebenen Tenant authentifizieren. Auf diese Weise kann sich der Nutzer ohne einen Zwischenprozess zur Identifizierung des Ziel-Tenants authentifizieren.

In diesem Szenario gibt es noch weitere Komplikationen. Stell dir zum Beispiel vor, dass alle deine Benutzer in einer gemeinsamen Identitätsanbieter-Konstruktion arbeiten. In diesem Fall verlangt der Identitätsanbieter, dass jeder Benutzer eindeutig ist. Das würde es unmöglich machen, eine einzige Benutzer-ID mit mehreren Tenants zu verknüpfen. Stattdessen solltest du dir überlegen, ob du die Daten der einzelnen Tenants nicht in einem detaillierteren Konstrukt (wie dem bereits erwähnten Benutzerpool) speichern möchtest.

Mieterauthentifizierung ist keine Mieterisolierung

Im Rahmen dieser Diskussion über Authentifizierung und JWTs stelle ich manchmal fest, dass Teams die Authentifizierung mit Tenant Isolation gleichsetzen. Dabei wird davon ausgegangen, dass die Authentifizierung die Einstiegshürde für Mandanten ist und dass man die Kriterien für die Mandantenisolierung in mandantenfähigen Umgebungen erfüllt hat, sobald man diese Herausforderung überwunden hat.

Dies ist definitiv ein Bereich, in dem die Verbindung nicht stimmt. Ja, mit der Authentifizierung beginnt die Isolierung, indem ein JWT mit Tenant-Kontext ausgegeben wird. Der Code in deinen Microservices kann jedoch immer noch Implementierungen enthalten, die - auch wenn sie im Namen eines authentifizierten Nutzers arbeiten - auf die Ressourcen eines anderen Tenants zugreifen können. Die Tenant-Isolation baut auf dem Tenant-Kontext auf, den du von einem authentifizierten Nutzer erhältst, und implementiert eine völlig separate Schicht von Kontrollen und Maßnahmen, um sicherzustellen, dass dein Code die Tenant-Grenze nicht überschreiten darf. Einen tieferen Einblick in diese Strategien bekommst du in Kapitel 9.

Fazit

In diesem Kapitel ging es darum, die grundlegenden Elemente zu beschreiben, die den Ausgangspunkt für den Aufbau einer mandantenfähigen Architektur bilden. Ich habe mich darauf konzentriert, die Kernkonstrukte vorzustellen, die verwendet werden, um das Konzept der Mandantenfähigkeit in deine Architektur zu integrieren. Du wirst feststellen, dass in diesen ersten Schritten keine Anstrengungen unternommen werden, um das Anwendungserlebnis zu definieren. Stattdessen geht es darum, Tenancy in den Mittelpunkt deiner Architektur zu stellen. Wenn du diese grundlegenden Voraussetzungen frühzeitig schaffst, muss dein Team in allen Phasen deines Entwicklungsprozesses einen mandantenfähigen Kontext entwerfen, erstellen, testen und betreiben. Vom ersten Tag an muss deine Architektur alle Dynamiken berücksichtigen, die mit der Unterstützung mehrerer Mieter einhergehen. Das übergeordnete Ziel ist es, die Falle zu vermeiden, Multi-Tenant als ein Zusatzmodul zu betrachten, das nach der Entwicklung deiner Anwendung hinzugefügt werden kann. Dieser Modus funktioniert selten und führt in der Regel zu schmerzhaften Kompromissen und Nachbesserungen.

Wir haben das Kapitel auf der grundlegendsten Ebene begonnen, indem wir den Prozess der Erstellung deiner Basisumgebung und der Bereitstellung der ersten Teile deiner Control Plane untersucht haben. Wenn du das Grundgerüst der Control Plane fertiggestellt hast, kannst du den Raum abstecken, in dem später alle dazugehörigen Dienste untergebracht werden. Außerdem musst du dir nun Gedanken über die Bereitstellung, die Versionierung und den allgemeinen Lebenszyklus deiner Control Plane machen.

Danach haben wir unsere Aufmerksamkeit auf das Onboarding gerichtet und die Komplexität, die Herausforderungen und die Überlegungen, die mit der Einführung von Mietern in deine Umgebung einhergehen, hervorgehoben. Wir haben uns einen konzeptionellen Überblick über den Onboarding-Prozess verschafft, um dir ein besseres Gefühl für die beweglichen Teile zu vermitteln, die zu diesem Prozess gehören. Ein großer Teil dieser Diskussion drehte sich auch um die Denkweise, die mit der Automatisierung deines Onboarding-Prozesses einhergeht. Hier haben wir gesehen, wie die Automatisierung des Onboardings neue DevOps-Nuancen in deine Umgebung bringt und wie du darüber nachdenken kannst, wo und wann Tenant-Umgebungen bereitgestellt und konfiguriert werden. Unser Blick auf das Onboarding hat auch gezeigt, welche Rolle es bei der Unterstützung und Ermöglichung der Skalierungs-, Agilitäts- und Innovationsziele deines Unternehmens spielt.

Beim Onboarding haben wir darüber gesprochen, wie Tenants in deine Umgebung eingeführt werden. Es lag nahe, sich anzusehen, wie die Einrichtung dieser Tenants die Authentifizierung in deiner Umgebung beeinflusst. Bei der Authentifizierung zeigt sich, dass sich die Arbeit, die beim Onboarding geleistet wurde, auszahlt. Bei der Überprüfung der Authentifizierung haben wir uns auf die Rolle der Identität in einer SaaS-Umgebung konzentriert. Wir haben untersucht, wie unser Identitätsanbieter eine Verbindung zwischen Nutzern und Mietern herstellt und so eine sogenannte SaaS-Identität schafft. Das macht die SaaS-Identität zu einem erstklassigen Konzept in unserer Architektur. Wir haben untersucht, wie die Authentifizierung von Mietern zu Token führt, die den gesamten Kontext enthalten, den wir für alle nachgelagerten Teile unserer SaaS-Architektur benötigen. Dies sollte verdeutlichen, wie wichtig es ist, die SaaS-Identität von Anfang an in den Aufbau einer mandantenfähigen Umgebung zu integrieren.

Ich habe zwar nur die konzeptionellen Elemente von Onboarding und Identität angesprochen, aber das sollte dir ein besseres Gefühl für die beweglichen Teile und Überlegungen geben, die mit der Erstellung dieser grundlegenden Konstrukte einhergehen. Im weiteren Verlauf werden wir konkretere Versionen dieser Mechanismen kennenlernen und sehen, wie unterschiedliche Bereitstellungsmodelle und Technologiepakete die Gestaltung und Umsetzung von Onboarding und Identität beeinflussen können. Der Tenant-Kontext wird auch bei der Betrachtung anderer Dimensionen deiner Architektur eine Rolle spielen, z. B. bei der Datenpartitionierung, der Tenant-Isolierung, den Multi-Tenant-Microservices und so weiter.

Zunächst werden wir jedoch einen Blick in die Kontrollebene werfen und die Komponente Tenant Management untersuchen. In diesem Kapitel wurde bereits angedeutet, wie Tenant Management als Teil des Onboarding-Erlebnisses auftaucht. Jetzt möchte ich die Rolle dieses Dienstes innerhalb der Control Plane genauer beleuchten. Er ist zwar nicht exotisch oder übermäßig komplex, aber er steht oft im Mittelpunkt unserer Multi-Tenant-Geschichte. Ich werde darauf eingehen, was es bedeutet, diesen Dienst einzurichten, und einige der wichtigsten Überlegungen darlegen, die seine Implementierung beeinflussen können.

Get Aufbau von mandantenfähigen SaaS-Architekturen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Kapitel 4. Onboarding und Identität

Erstellen einer grundlegenden Umgebung

Abbildung 4-1. Automatisieren der Erstellung einer Baseline-Umgebung

Erstellen deiner Basisumgebung

Abbildung 4-2. Bereitstellen einer Baseline-Umgebung

Abbildung 4-3. Erstellen und Bereitstellen einer Systemadministrationskonsole

Erstellen und Verwalten von Systemadministrator-Identitäten

Onboarding über die Admin-Konsole auslösen

Optionen für die Bereitstellung der Control Plane

Abbildung 4-4. Auswahl eines Bereitstellungsmodells für die Kontrollebene

Das Onboarding-Erlebnis

Onboarding ist Teil deines Service

Selbstbedienung versus internes Onboarding

Die grundlegenden Teile des Onboarding

Abbildung 4-5. Die Grundlagen des Tenant Onboarding

Verfolgen und Aufdecken von Onboarding-Zuständen

Stufenbasiertes Onboarding

Abbildung 4-6. Ein Beispiel für tierbasiertes Onboarding

Abbildung 4-7. Tier-basiertes Onboarding mit gemischten Einsatzmodi

Verfolgung der eingebrachten Ressourcen

Umgang mit Onboarding-Fehlern

Abbildung 4-8. Fehlertolerante Integration mit einem Abrechnungsanbieter

Teste dein Onboarding-Erlebnis

Eine SaaS-Identität schaffen

Abbildung 4-9. Erstellen einer logischen SaaS-Identität

Abbildung 4-10. Fluss der SaaS-Identitätsauthentifizierung

Anbringen einer Mieteridentität

Abbildung 4-11. Hinzufügen von mietereigenen Ansprüchen zu einem JWT

Abbildung 4-12. Authentifizierung mit eingebettetem Mandantenkontext

Abbildung 4-13. Weitergabe von Token an nachgelagerte Microservices

Benutzerdefinierte Ansprüche beim Onboarding eingeben

Sorgfältige Verwendung von Zollansprüchen

Keine zentralen Dienste für die Lösung des Mieterkontextes

Abbildung 4-14. Verwendung eines separaten Benutzer/Mieter-Zuordnungsdienstes

Föderierte SaaS-Identität

Abbildung 4-15. Unterstützung von extern gehosteten Identitätsanbietern

Mietergruppierung/Mapping-Konstrukte

Gemeinsame Nutzung von Benutzer-IDs durch verschiedene Mieter

Mieterauthentifizierung ist keine Mieterisolierung

Fazit

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly