Bearbeiten

Starter-Web-App für die SaaS-Entwicklung

Azure App Service
Microsoft Entra External ID
Azure SQL-Datenbank
Azure Logic Apps
Azure Resource Manager

SaaS (Software-as-a-Service) ist ein komplexes Thema, bei dem viele Punkte zu beachten sind. Unabhängige Softwareanbieter (ISVs), die ihre SaaS-Lösungen in Azure erstellen, müssen Probleme lösen und Entscheidungen treffen, wie etwa die folgenden:

  • Welches Mandantenmodell sollte ich verwenden?
  • Wie richte ich eine Identitätslösung für die Verwendung in einer mehrinstanzenfähigen Architektur ein?
  • Wie gehe ich beim Onboarding neuer Kunden vor?

Diese Architektur soll einige dieser Fragen beantworten und einen Einstieg in die Welt von SaaS bieten. Diese Architektur lässt sich an eine Vielzahl von Szenarien anpassen.

Mögliche Anwendungsfälle

Im Folgenden finden Sie einige Anwendungsbeispiele, in denen Sie diese Architektur verwenden können:

  • Modernisieren Sie eine bestehende Anwendung, um im Rahmen einer Umstellung auf ein SaaS-basiertes Geschäftsmodell die uneingeschränkte Mehrinstanzenfähigkeit zu unterstützen.
  • Entwickeln Sie ein völlig neues SaaS-Angebot.
  • Migrieren Sie ein SaaS-Angebot von einem anderen Clouddienst zu Azure.

Aufbau

Architekturdiagramm, das die Steuerungsebene, das Identitäts-Framework und die SaaS-Anwendung für den Endbenutzer zeigt.

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Begriff

In der folgenden Tabelle sind Begriffe beschrieben, die in diesem Artikel vorkommen.

Begriff BESCHREIBUNG Beispiel
SaaS-Anbieter oder ISV Die Entität, die Besitzer der SaaS-Anwendung und des Codes ist und das SaaS-Produkt vertreibt. Contoso Inc. verkauft seine SaaS-Anwendung: Contoso Tickets.
Tenant Eine erworbene Instanz der SaaS-Anwendung vom SaaS-Anbieter. Fourth Coffee Shop.
SaaS-Kundenadministrator Personen, die einen Anwendungsmandanten kaufen oder verwalten. Joe, Besitzer des Fourth Coffee Shop.
SaaS-Kundenbenutzer Personen, die einen Anwendungsmandanten verwenden, ohne ihn zu verwalten, und die in der Regel demselben Unternehmen oder derselben Gruppe angehören wie der SaaS-Kundenadministrator. Jill, Eventmanagerin im Fourth Coffee Shop, und Susan, Kundin des Fourth Coffee Shop.
Endbenutzer Ein SaaS-Kundenadministrator, ein SaaS-Kundenbenutzer oder jeder andere Benutzertyp, der eingeführt wird. Dies ist ein allgemeiner Begriff zur Beschreibung von Benutzern, die sich bei der Anwendung anmelden. Joe, Jill und Susan sind alle Endbenutzer (aus Sicht des ISV).
Front-End-Anwendung Eine beliebige Front-End-Anwendung. Die Onboarding- und Admin-App und die SaaS-App sind beides Front-End-Anwendungen.

Workflow

  1. Der SaaS-Kundenadministrator navigiert zu der Website, die in der Onboarding- und Admin-App gehostet wird.

  2. Der SaaS-Kundenadministrator meldet sich mithilfe des Workflows für die Benutzeranmeldung an.

  3. Der SaaS-Kundenadministrator schließt den Onboarding-Flow ab.

  4. Der SaaS-Kundenadministrator navigiert zum Mandantenadministratorbereich in der Onboarding- und Admin-App und fügt dem neu erstellten Mandanten einen SaaS-Kundenbenutzer hinzu.

  5. Der SaaS-Kundenbenutzer navigiert zur SaaS-Anwendungs-App und verwendet die SaaS-Anwendung.

Benutzeranmeldung

Der Workflow für die Benutzeranmeldung umfasst die folgenden Schritte:

Ablaufdiagramm, das den Anmeldevorgang für einen Benutzer zeigt.

  1. Der Endbenutzer navigiert zu einer Front-End-Anwendung und wählt eine Anmeldeschaltfläche aus.

  2. Die Front-End-Anwendung leitet den Endbenutzer zu einer Anmeldeseite um, die vom Identitätsanbieter gehostet wird.

  3. Der Endbenutzer gibt Kontoinformationen ein und sendet das Anmeldeformular an den Identitätsanbieter.

  4. Der Identitätsanbieterstellt eine POST-Anforderung mit der E-Mail-Adresse und Objekt-ID des Endbenutzers aus, um ihre Berechtigungen und Rollen abzurufen.

  5. Die Berechtigungsdaten-API sucht die Informationen des Endbenutzers im Berechtigungsdatenspeicher und gibt eine Liste der Berechtigungen und Rollen zurück, die diesem Endbenutzer zugewiesen sind.

  6. Der Identitätsanbieter fügt die Berechtigungen und Rollen als benutzerdefinierte Ansprüche zum ID-Token hinzu, wobei es sich um ein JSON-Webtoken (JWT) handelt.

  7. Der Identitätsanbieter gibt ein ID-Token an den Endbenutzer zurück und initiiert eine Umleitung zur Front-End-Anwendung.

  8. Der Endbenutzer wird zum Anmeldeendpunkt der Front-End-Anwendung umgeleitet und stellt das ID-Token dar.

  9. Die Front-End-Anwendung überprüft das angezeigte ID-Token.

  10. Die Front-End-Anwendung gibt eine Seite zur erfolgreichen Anmeldung zurück, und der Endbenutzer ist jetzt angemeldet.

Weitere Informationen zur Funktionsweise dieses Anmeldeflusses finden Sie im OpenID Connect-Protokoll.

Onboarding eines neuen Mandanten

Der Workflow für das Onboarding von Mandanten besteht aus den folgenden Schritten:

Ablaufdiagramm, das den Prozess für das Onboarding von Mandanten zeigt.

  1. Der SaaS-Kundenadministrator navigiert zur Onboarding- und Admin-App und führt ein Anmeldeformular aus.

  2. Die Onboarding- und Admin-App stellt eine POST-Anforderung für die Mandantendaten-API aus, um einen neuen Mandanten zu erstellen.

  3. Die Mandantendaten-API erstellt einen neuen Mandanten im Mandantendatenspeicher.

  4. Die Mandantendaten-API stellt eine POST-Anforderung für die Berechtigungsdaten-API aus, um dem SaaS-Kundenadministrator Berechtigungen für den neu erstellten Mandanten zu gewähren.

  5. Die Berechtigungsdaten-API erstellt einen neuen Berechtigungsdatensatz im Berechtigungsdatenspeicher.

  6. Die Berechtigungsdaten-API nimmt eine erfolgreiche Rückgabe vor.

  7. Die Mandantendaten-API nimmt eine erfolgreiche Rückgabe vor.

  8. Die Onboarding- und Admin-App sendet eine POST-Anforderung an den E-Mail-Benachrichtigungsanbieter, um eine E-Mail-Nachricht mit der Information „Mandant erstellt“ an den SaaS-Kundenadministrator zu senden.

  9. Der E-Mail-Benachrichtigungsanbieter sendet die E-Mail.

  10. Der E-Mail-Benachrichtigungsanbieter nimmt eine erfolgreiche Rückgabe vor.

  11. Die Onboarding- und Admin-App sendet eine Anforderung an den Identitätsanbieter, um das SaaS-ID-Token des SaaS-Kundenadministrators zu aktualisieren, sodass es einen JWT-Anspruch auf den neu erstellten Mandanten enthält.

  12. Der Identitätsanbieterstellt eine POST-Anforderung mit der E-Mail-Adresse und Objekt-ID des SaaS-Kundenadministrators aus, um ihre Berechtigungen und Rollen abzurufen.

  13. Die Berechtigungsdaten-API sucht die Informationen des SaaS-Kundenadministrators im Berechtigungsdatenspeicher und gibt eine Liste der dem SaaS-Kundenadministrator zugewiesenen Berechtigungen und Rollen zurück.

  14. Der Identitätsanbieter fügt die Berechtigungen und Rollen als benutzerdefinierte Ansprüche zum ID-Token hinzu.

  15. Der Identitätsanbieter gibt das ID-Token an die Onboarding- und Admin-App zurück.

  16. Die Onboarding- und Admin-App gibt eine Erfolgsnachricht und ein neues ID-Token an den SaaS-Kundenadministrator zurück.

Hinzufügen eines Benutzers zu einem Mandanten

Das Hinzufügen eines Benutzers zu einem Mandantenworkflow umfasst die folgenden Schritte:

Ablaufdiagramm, das das Hinzufügen eines neuen Benutzers zu einem Mandanten zeigt.

  1. Der SaaS-Kundenadministrator fordert eine Liste der Mandanten aus dem Mandantenadministratorbereich auf der Onboarding- und Admin-App an.

  2. Die Onboarding- und Admin-App sendet eine GET-Anforderung an die Mandantendaten-API, um eine Liste der Mandanten für den SaaS-Kundenadministrator abzurufen.

  3. Die Mandantendaten-API sendet eine GET-Anforderung an die Berechtigungsdaten-API, um eine Liste von Mandanten abzurufen, die der SaaS-Kundenadministrator anzeigen kann.

  4. Die Berechtigungsdaten-API gibt eine Liste der Mandantenberechtigungen zurück.

  5. Die Mandantendaten-API sucht die Mandanteninformationen im Mandantendatenspeicher und gibt eine Liste der Mandantendaten basierend auf der empfangenen Liste der Mandantenberechtigungen zurück.

  6. Die Onboarding- und Admin-App gibt die Liste der Mandantendaten an den SaaS-Kundenadministrator zurück.

  7. Der SaaS-Kundenadministrator wählt einen Mandanten aus der Liste aus, dem er einen SaaS-Kundenbenutzer hinzuzufügen möchte, und gibt die E-Mail-Adresse für den SaaS-Kundenbenutzer ein.

  8. Die Onboarding- und Admin-App sendet eine POST-Anforderung an die Mandantendaten-API, um dem SaaS-Kundenbenutzer eine Berechtigung für den angegebenen Mandanten hinzuzufügen.

  9. Die Mandantendaten-API überprüft, dass der SaaS-Kundenadministrator einen gültigen JWT-Anspruch auf den angegebenen Mandanten hat und über die Schreibberechtigung des Benutzers für diesen verfügt.

  10. Die Mandantendaten-API sendet eine POST-Anforderung an die Berechtigungsdaten-API, um dem SaaS-Kundenbenutzer eine Berechtigung für den angegebenen Mandanten hinzuzufügen.

  11. Die Berechtigungsdaten-API sendet eine GET-Anforderung an den Identitätsanbieter, um den SaaS-Kundenbenutzer nach der angegebenen E-Mail-Adresse zu suchen.

  12. Der Identitätsanbieter gibt die Objekt-ID des SaaS-Kundenbenutzers zurück.

  13. Die Berechtigungsdaten-API fügt einen Berechtigungsdatensatz in den Berechtigungsdatenspeicher für den SaaS-Kundenbenutzer auf dem angegebenen Mandanten mithilfe seiner Objekt-ID hinzu.

  14. Die Berechtigungsdaten-API nimmt eine erfolgreiche Rückgabe vor.

  15. Die Mandantendaten-API nimmt eine erfolgreiche Rückgabe vor.

  16. Die Onboarding- und Admin-App nimmt eine erfolgreiche Rückgabe vor.

Komponenten

Diese Architektur verwendet die folgenden Azure-Dienste:

  • App Service ermöglicht das Erstellen und Hosten von Web- und API-Apps in der Programmiersprache Ihrer Wahl, ohne eine Infrastruktur verwalten zu müssen.

  • Azure Active Directory B2C ermöglicht eine einfache Identitäts- und Zugriffsverwaltung für Anwendungen von Endbenutzern.

  • Azure SQL-Datenbank ist ein universeller verwalteter Dienst mit einer relationalen Datenbank, die Strukturen wie relationale Daten, räumliche Daten, JSON und XML unterstützt.

  • Azure Logic Apps ermöglicht es Ihnen, mithilfe eines einfachen GUI-Tools schnell leistungsstarke Integrationen zu erstellen.

Alternativen

Die Effektivität der alternativen Möglichkeiten hängt stark von dem Mandantenmodell ab, das Sie mit Ihrer SaaS-Anwendung unterstützen möchten. Im Folgenden finden Sie einige Beispiele für alternative Ansätze, die Sie bei der Implementierung dieser Lösung verfolgen können:

  • Die aktuelle Lösung verwendet Azure Active Directory B2C als Identitätsanbieter. Sie können stattdessen andere Identitätsanbieter wie Microsoft Entra ID verwenden.

  • Für strengere Sicherheits- und Complianceanforderungen können Sie sich entscheiden, private Netzwerke für die dienstübergreifende Kommunikation zu implementieren.

  • Anstatt REST-Aufrufe zwischen Diensten zu verwenden, könnten Sie einen ereignisgesteuerten Architekturstil für dienstübergreifendes Messaging implementieren.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads befolgen können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Diese Lösung stützt sich auf die Identität als Sicherheitsparadigma. Die Authentifizierung und Autorisierung für die Web-Apps und APIs wird durch die Microsoft Identity Platform geregelt, die für das Ausgeben und Überprüfen von Benutzer*innen-ID-Token (JWTs) verantwortlich ist.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Die Komponenten dieser Lösung sind mit gewissen Betriebskosten verbunden, die jedoch bei den meisten Webanwendungen und SaaS-Lösungen gering sind. Außerdem können Sie die Kosten kontrollieren, indem Sie die folgenden Ressourceneinstellungen verwalten:

  • Sie können den App Service-Plan, der die Anwendung ausführt, so skalieren, dass er dem von Ihnen benötigten Durchsatz entspricht. Außerdem können Sie jede App in einem separaten Plan ausführen, wenn Sie einen höheren Durchsatz benötigen, aber dann entstehen Ihnen höhere Kosten. Weitere Informationen hierzu finden Sie in der Übersicht über Azure App Service-Pläne.

  • Azure AD B2C bietet zwei SKUs: Premium P1 und Premium P2. Beide SKUs enthalten ein kostenloses Kontingent für die Anzahl der monatlich aktiven Benutzer (MAUs), aber Sie müssen prüfen, welche Features die einzelnen SKUs bieten, um festzustellen, welche für Ihren Anwendungsfall erforderlich ist. Weitere Informationen finden Sie unter Preise für die Microsoft Entra External ID.

  • Azure SQL verfügt über verschiedene Kaufmodelle, die für eine Vielzahl von Anwendungsfällen geeignet sind, einschließlich der Möglichkeit zur Autoskalierung. Sie müssen die Nutzung Ihrer eigenen Datenbanken bewerten, um sicherzustellen, dass Sie sie richtig dimensionieren. Weitere Informationen finden Sie unter vCore- und DTU-basierte Kaufmodelle von Azure SQL-Datenbank im Vergleich.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Diese Architektur sollte so skalierbar sein, dass sie die meisten mittleren bis großen Workloads problemlos bewältigen kann. Da die Architektur größtenteils die Plattformdienste (PaaS) von Azure verwendet, haben Sie viele Möglichkeiten, die Skalierung der Lösung an Ihre Anforderungen und Ihre Last anzupassen.

Bereitstellen dieses Szenarios

Wenn Sie dieses Szenario bereitstellen möchten, finden Sie weitere Informationen unter dem Azure SaaS Dev Kit auf GitHub. Es handelt sich um eine bereitstellungsfähige Referenzimplementierung dieser Architektur.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

Nächste Schritte

Hier sind einige zusätzliche empfohlene Ressourcen zum Erstellen einer SaaS-Anwendung in Azure aufgeführt: