Redigera

Startwebbapp för SaaS-utveckling

Azure App Service
Externt ID för Microsoft Entra
Azure SQL Database
Azure Logic Apps
Azure Resource Manager

Programvara som en tjänst (SaaS) är ett komplext ämne med många saker att tänka på. Oberoende programvaruleverantörer (ISV:er) som skapar sina SaaS-lösningar i Azure måste lösa problem och fatta beslut som:

  • Vilken innehavarmodell ska jag använda?
  • Hur gör jag för att konfigurera en identitetslösning för användning i en arkitektur med flera klientorganisationer?
  • Hur gör jag för att hantera registrering av nya kunder?

Den här arkitekturen syftar till att besvara några av dessa frågor och ge en startplats i SaaS värld. Den här arkitekturen är anpassningsbar för att passa en mängd olika scenarier.

Potentiella användningsfall

Följande är några exempel på användningsfall där du kan använda den här arkitekturen:

  • Modernisera ett befintligt program för att stödja fullständig multitenancy som en del av en övergång till en SaaS-baserad affärsmodell.
  • Utveckla ett helt nytt SaaS-erbjudande.
  • Migrera ett SaaS-erbjudande från en annan molntjänst till Azure.

Arkitektur

Arkitekturdiagram som visar kontrollplanet, identitetsramverket och slutanvändaren S ett S-program.

Ladda ned en PowerPoint-fil med den här arkitekturen.

Terminologi

I följande tabell beskrivs termer som visas i den här artikeln.

Period beskrivning Exempel
SaaS-leverantör eller ISV Entiteten som äger SaaS-programmet och koden och säljer SaaS-produkten. Contoso Inc, som säljer sin SaaS-app: Contoso Tickets.
Klientorganisation En köpt instans av SaaS-programmet från SaaS-leverantören. Fjärde kaféet.
SaaS-kundadministratör Personer som köper eller administrerar en programklientorganisation. Joe, ägare av Fourth Coffee Shop.
SaaS-kundanvändare Personer som använder en programklientorganisation utan att administrera den och vanligtvis tillhör samma företag eller grupp som SaaS-kundadministratören. Jill, event manager på Fourth Coffee Shop, och Susan, kund på Fourth Coffee Shop.
Slutanvändare En SaaS-kundadministratör, SaaS-kundanvändare eller andra användartyper som introduceras. Det här är en allmän term för att beskriva användare som loggar in i programmet. Joe, Jill och Susan är alla slutanvändare (från ISV-perspektivet).
Klientdelsprogram Alla klientdelsprogram. Både onboarding- och administratörsappen och SaaS-appen är klientdelsprogram.

Arbetsflöde

  1. SaaS-kundadministratören navigerar till den webbplats som finns i onboarding- och administratörsappen.

  2. SaaS-kundadministratören loggar in med hjälp av arbetsflödet för användarinloggning.

  3. SaaS-kundadministratörenslutför onboarding-flödet.

  4. SaaS-kundadministratören navigerar till administrationsområdet för klientorganisationen i appen Registrering och administratör och lägger till en SaaS-kundanvändare i sin nyligen skapade klientorganisation.

  5. SaaS-kundanvändaren navigerar till SaaS-programappen och använder SaaS-programmet.

Användarinloggning

Arbetsflödet för användarinloggning består av följande steg:

Sekvensdiagram som visar inloggningsprocessen för en användare.

  1. Slutanvändaren navigerar till ett klientdelsprogram och väljer en inloggningsknapp.

  2. Klientdelsprogrammet omdirigerar slutanvändaren till en inloggningssida som värdhanteras av identitetsprovidern.

  3. Slutanvändaren anger kontoinformation och skickar inloggningsformuläret till identitetsprovidern.

  4. Identitetsprovidern utfärdar en POST-begäran med slutanvändarens e-postadress och objekt-ID för att hämta deras behörigheter och roller.

  5. API:et för behörighetsdata söker efter slutanvändarens information i lagring av behörighetsdata och returnerar en lista över behörigheter och roller som har tilldelats till slutanvändaren.

  6. Identitetsprovidern lägger till behörigheter och roller som anpassade anspråk till ID-token, vilket är en JSON-webbtoken (JWT).

  7. Identitetsprovidern returnerar en ID-token till slutanvändarenoch initierar en omdirigering till klientdelsprogrammet.

  8. Slutanvändaren omdirigeras till inloggningsslutpunkten i klientdelsprogrammet och visar ID-token.

  9. Klientdelsprogrammet verifierar den presenterade ID-token.

  10. Klientdelsprogrammet returnerar en lyckad inloggningssida och slutanvändaren är nu inloggad.

Mer information om hur det här inloggningsflödet fungerar finns i OpenID Anslut protocol.

Registrera en ny klientorganisation

Arbetsflödet för registrering av klientorganisation består av följande steg:

Sekvensdiagram som visar processen för klientregistrering.

  1. SaaS-kundadministratören navigerar till registrerings- och administratörsappen och fyller i ett registreringsformulär.

  2. Registrerings- och administratörsappen skickar en POST-begäran till API:et för klientdata för att skapa en ny klientorganisation.

  3. Klientdata-API:et skapar en ny klientorganisation i klientdatalagringen.

  4. Klientdata-API:et utfärdar en POST-begäran till API:et för behörighetsdata för att bevilja SaaS-kundadministratörsbehörigheter till den nyligen skapade klientorganisationen.

  5. API:et Behörighetsdata skapar en ny behörighetspost i behörighetsdatalagringen.

  6. API:et för behörighetsdata returnerar korrekt.

  7. Klientdata-API:et returnerar korrekt.

  8. Registrerings- och administratörsappen skickar en POST-begäran till e-postaviseringsprovidern för att skicka ett e-postmeddelande med "klientorganisation som skapats" till SaaS-kundadministratören.

  9. E-postaviseringsprovidern skickar e-postmeddelandet.

  10. E-postaviseringsprovidern returnerar korrekt.

  11. Registrerings- och administratörsappenskickar en begäran till identitetsprovidern om att uppdatera SaaS-kundadministratörens ID-token så att den inkluderar ett JWT-anspråk till den nyligen skapade klientorganisationen.

  12. Identitetsprovidern utfärdar en POST-begäran med SaaS-kundadministratörens e-postadress och objekt-ID för att hämta deras behörigheter och roller.

  13. API:et för behörighetsdata letar upp SaaS-kundadministratörens information i behörighetsdatalagringenoch returnerar en lista över behörigheter och roller som tilldelats SaaS-kundadministratören.

  14. Identitetsprovidern lägger till behörigheter och roller som anpassade anspråk till ID-token.

  15. Identitetsprovidern returnerar ID-token till registrerings- och administratörsappen.

  16. Registrerings- och administratörsappen returnerar ett meddelande om lyckat resultat och en ny ID-token till SaaS-kundadministratören.

Lägga till en användare i en klientorganisation

Tillägget av en användare till ett klientarbetsflöde består av följande steg:

Sekvensdiagram som visar tillägget av en ny användare till en klientorganisation.

  1. SaaS-kundadministratören begär att få se en lista över klienter från administrationsområdet för klientorganisationen i appen Registrering och administratör.

  2. Registrerings- och administratörsappen skickar en GET-begäran till KLIENTdata-API:et för att hämta en lista över klienter för SaaS-kundadministratören.

  3. Klientdata-API:et utfärdar en GET-begäran till API:et för behörighetsdata för att hämta en lista över klienter som SaaS-kundadministratören har åtkomst till att visa.

  4. API:et behörighetsdata returnerar en lista över klientbehörigheter.

  5. Klientdata-API:et letar upp klientinformationen i klientdatalagringen och returnerar en lista över klientdata baserat på listan över klientbehörigheter som tagits emot.

  6. Appen Onboarding &admin returnerar listan över klientdata till SaaS-kundadministratören.

  7. SaaS-kundadministratören väljer en klientorganisation i listan för att lägga till en SaaS-kundanvändare i och anger e-postadressen för SaaS-kundanvändaren.

  8. Registrerings- och administratörsappen utfärdar en POST-begäran till API:et för klientdata för att lägga till en behörighet för SaaS-kundanvändaren i den angivna klientorganisationen.

  9. Api:et för klientdata verifierar att SaaS-kundadministratören har ett giltigt JWT-anspråk till den angivna klientorganisationen och har användarens skrivbehörighet.

  10. Klientdata-API:et utfärdar en POST-begäran till API:et Behörighetsdata för att lägga till en behörighet för SaaS-kundanvändaren i den angivna klientorganisationen.

  11. API:et för behörighetsdata skickar en GET-begäran till identitetsprovidern för att söka efter SaaS-kundanvändaren via den angivna e-postadressen.

  12. Identitetsprovidern returnerar SaaS-kundanvändarens objekt-ID.

  13. API:et Behörighetsdata lägger till en behörighetspost i Behörighetsdatalagring för SaaS-kundanvändaren i den angivna klientorganisationen med hjälp av deras objekt-ID.

  14. API:et för behörighetsdata returnerar korrekt.

  15. Klientdata-API:et returnerar korrekt.

  16. Registrerings - och administratörsappen returnerar korrekt.

Komponenter

Den här arkitekturen använder följande Azure-tjänster:

  • Med App Service kan du skapa och vara värd för webbappar och API-appar på det programmeringsspråk som du väljer utan att behöva hantera infrastrukturen.

  • Azure Active Directory B2C möjliggör enkelt identitets- och åtkomsthantering för slutanvändarprogram.

  • Azure SQL Database är en hanterad tjänst för relationsdatabaser som har stöd för relationsdata, rumsliga data, JSON och XML.

  • Med Azure Logic Apps kan du snabbt skapa kraftfulla integreringar med hjälp av ett enkelt GUI-verktyg.

Alternativ

Hur effektiva alternativa alternativ som helst beror mycket på vilken innehavarmodell som du har för avsikt att stödja ditt SaaS-program. Följande är några exempel på alternativa metoder som du kan följa när du implementerar den här lösningen:

  • Den aktuella lösningen använder Azure Active Directory B2C som identitetsprovider. Du kan i stället använda andra identitetsprovidrar, till exempel Microsoft Entra-ID.

  • För striktare säkerhet och efterlevnadskrav kan du välja att implementera privata nätverk för kommunikation mellan tjänster.

  • I stället för att använda REST-anrop mellan tjänster kan du implementera en händelsedriven arkitekturstil för meddelanden mellan tjänster.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan följa för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Den här lösningen förlitar sig på identitet som säkerhetsparadigm. Autentisering och auktorisering för webbappar och API:er styrs av Microsofts identitetsplattform, som ansvarar för att utfärda och verifiera användar-ID-token (JWT).

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Komponenterna i den här lösningen har en viss kostnad i samband med driften, men kostnaden är blygsam för de flesta webbprogram och SaaS-lösningar. Du kan också styra kostnaden genom att hantera följande resursinställningar:

  • Du kan skala den App Service-plan som kör programmet för att passa det dataflöde som du behöver. Dessutom kan du köra varje app på en separat plan om du behöver högre dataflöde, men du får därför en högre kostnad. Mer information finns i Översikt över Azure App Service-plan.

  • Azure AD B2C innehåller två SKU:er: Premium P1 och Premium P2. Båda SKU:erna innehåller en kostnadsfri ersättning för antalet månatliga aktiva användare (MAUs), men du måste utvärdera vilka funktioner som varje SKU tillhandahåller för att avgöra vilka som krävs för ditt användningsfall. Mer information finns i Prissättning för externt ID för Microsoft Entra.

  • Azure SQL har flera köpmodeller som passar en mängd olika användningsfall, inklusive möjligheten att autoskala. Du måste utvärdera användningen på dina egna databaser för att se till att du har rätt storlek på dem. Mer information finns i Jämför virtuella kärnor och DTU-baserade köpmodeller för Azure SQL Database.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

Den här arkitekturen bör kunna skalas för att enkelt uppfylla de flesta medelstora till medelstora arbetsbelastningar. Eftersom arkitekturen främst använder Azures plattformstjänster (PaaS) har du många alternativ för att justera lösningens skala baserat på dina krav och din belastning.

Distribuera det här scenariot

Om du vill distribuera det här scenariot kan du läsa Azure SaaS Dev Kit på GitHub. Det är en distributionsbar referensimplementering av den här arkitekturen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Nästa steg

Här följer några ytterligare rekommenderade resurser för att skapa ett SaaS-program i Azure: