Freigeben über

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 Mandantmodell 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ätsframework und den EndbenutzerN S a a S-Anwendung zeigt.

Laden Sie eine PowerPoint-Datei 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.
Mieter Eine erworbene Instanz der SaaS-Anwendung vom SaaS-Anbieter. Vierter Café.
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.

Arbeitsablauf

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

  2. Der SaaS-Kundenadministrator meldet sich mit dem Benutzeranmeldungsworkflow an.

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

  4. Der SaaS-Kundenadministrator navigiert in der Onboarding& Admin-App zum Mandantenadministratorbereich 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:

Sequenzdiagramm, 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ätsanbietergibt eine POST-Anforderung mit der E-Mail-Adresse und Objekt-ID des Endbenutzers aus, um seine 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, bei dem 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 an den Anmeldeendpunkt in 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 erfolgreiche Anmeldeseite 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:

Sequenzdiagramm, das den Prozess für das Mandanten-Onboarding zeigt.

  1. Der SaaS-Kundenadministrator navigiert zur Onboarding & Admin-App und schließt ein Registrierungsformular ab.

  2. Die Onboarding & Admin-App gibt eine POST-Anforderung an die Mandantendaten-API aus, um einen neuen Mandanten zu erstellen.

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

  4. Die Mandantendaten-API gibt eine POST-Anforderung an die Berechtigungsdaten-API aus, um den SaaS-Kundenadministratorberechtigungen für den neu erstellten Mandanten zu erteilen.

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

  6. Die Berechtigungsdaten-API gibt erfolgreich zurück.

  7. Die Mandantendaten-API gibt erfolgreich zurück.

  8. Die Onboarding & Admin-App gibt eine POST-Anforderung an den E-Mail-Benachrichtigungsanbieter aus, um eine E-Mail-Nachricht vom Typ "Mandant erstellt" an den SaaS-Kundenadministrator zu senden.

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

  10. Der E-Mail-Benachrichtigungsanbieter wird erfolgreich zurückgegeben.

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

  12. Der Identitätsanbietergibt 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 Berechtigungen und Rollen zurück, die dem SaaS-Kundenadministrator zugewiesen sind.

  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 & Admin-App zurück.

  16. Die Onboarding & Admin-App gibt eine Erfolgsmeldung 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:

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

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

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

  3. Die Mandantendaten-API gibt eine GET-Anforderung an die Berechtigungsdaten-API aus, um eine Liste der Mandanten abzurufen, auf die der SaaS-Kundenadministrator Zugriff auf die Ansicht hat.

  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 Liste der empfangenen Mandantenberechtigungen zurück.

  6. Die Onboarding & 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, um einen SaaS-Kundenbenutzer hinzuzufügen und die E-Mail-Adresse für den SaaS-Kundenbenutzer einzugeben.

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

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

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

  11. Die Berechtigungsdaten-API gibt eine GET-Anforderung an den Identitätsanbieter aus, um den SaaS-Kundenbenutzer anhand der bereitgestellten E-Mail-Adresse nachzuschlagen.

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

  13. Die Berechtigungsdaten-API fügt einen Berechtigungsdatensatz im Berechtigungsdatenspeicher für den SaaS-Kundenbenutzer im angegebenen Mandanten mithilfe ihrer Objekt-ID hinzu.

  14. Die Berechtigungsdaten-API gibt erfolgreich zurück.

  15. Die Mandantendaten-API gibt erfolgreich zurück.

  16. Die Onboarding & Admin-App wird erfolgreich zurückgegeben.

Komponenten

Diese Architektur verwendet die folgenden Azure-Dienste:

  • Mit app Service können Sie Web-Apps und API-Apps in der von Ihnen ausgewählten Programmiersprache erstellen und hosten, ohne die Infrastruktur verwalten zu müssen.

  • Azure Active Directory B2C ermöglicht ganz einfach die Identitäts- und Zugriffsverwaltung für Endbenutzeranwendungen.

  • Azure SQL-Datenbank ist ein allgemeiner relationaler Datenbankverwalteter Dienst, der relationale Daten, räumliche Daten, JSON und XML unterstützt.

  • Mit Azure Logic Apps können Sie schnell leistungsstarke Integrationen mit einem einfachen grafischen Benutzeroberflächentool (GUI) erstellen.

Alternativen

Die Effektivität alternativer Auswahlmöglichkeiten hängt stark vom Mandantenmodell ab, das Sie für Ihre 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 verwenden, z. B. Microsoft Entra ID.

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

  • Statt 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 verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie in der Prüfliste zur Entwurfsüberprüfung für Sicherheit.

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

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie in der Prüfliste für die Entwurfsüberprüfung für die 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 für die Ausführung der Anwendung 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 finden Sie in der Übersicht über den Azure App Service-Plan.

  • 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 in den Preisen für externe Microsoft Entra-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 Vergleichen von vCore- und DTU-basierten Einkaufsmodellen von Azure SQL-Datenbank.

Leistungseffizienz

Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Workload, die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie in der Prüfliste zur Entwurfsüberprüfung für Die 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 (Platform-as-a-Service, 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, lesen Sie das 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: