Software as a Service (SaaS) is een complex onderwerp met veel punten waarmee u rekening moet houden. Onafhankelijke softwareleveranciers (ISV's) die hun SaaS-oplossingen in Azure bouwen, moeten problemen oplossen en beslissingen nemen, zoals:
- Welk tenancymodel moet ik gebruiken?
- Hoe kan ik een identiteitsoplossing instellen voor gebruik in een multitenant-architectuur?
- Hoe kan ik onboarding van nieuwe klanten afhandelen?
Deze architectuur is erop gericht om enkele van deze vragen te beantwoorden en een beginplaats te bieden in de wereld van SaaS. Deze architectuur kan worden aangepast aan een breed scala aan scenario's.
Potentiële gebruikscases
Hier volgen enkele voorbeelden van gebruiksvoorbeelden waarin u deze architectuur kunt gebruiken:
- Moderniseer een bestaande toepassing om volledige multitenancy te ondersteunen als onderdeel van een overstap naar een op SaaS gebaseerd bedrijfsmodel.
- Ontwikkel een volledig nieuwe SaaS-aanbieding.
- Migreer een SaaS-aanbieding van een andere cloudservice naar Azure.
Architectuur
Download een PowerPoint-bestand van deze architectuur.
Terminologie
In de volgende tabel worden termen beschreven die in dit artikel worden weergegeven.
| Termijn | Omschrijving | Voorbeeld |
|---|---|---|
| SaaS-leverancier of ISV | De entiteit die eigenaar is van de SaaS-toepassing en code en het SaaS-product verkoopt. | Contoso Inc, hun SaaS-toepassing verkopen: Contoso Tickets. |
| Tenant | Een aangeschaft exemplaar van de SaaS-toepassing van SaaS-leverancier. | Vierde koffiebar. |
| SaaS-klantbeheerder | Mensen wie een toepassingstenant koopt of beheert. | Joe, eigenaar van Fourth Coffee Shop. |
| SaaS-klantgebruiker | Mensen die een toepassingstenant gebruiken zonder deze te beheren en meestal behoren tot hetzelfde bedrijf of dezelfde groep als de SaaS-klantbeheerder. | Jill, event manager bij Fourth Coffee Shop en Susan, klant van Fourth Coffee Shop. |
| Eindgebruiker | Een SaaS-klantbeheerder, SaaS-klantgebruiker of andere typen gebruikers die worden geïntroduceerd. Dit is een algemene term om gebruikers te beschrijven die zich aanmelden bij de toepassing. | Joe, Jill en Susan zijn allemaal eindgebruikers (vanuit het perspectief van de ISV). |
| Front-endtoepassing | Elke front-endtoepassing. | De onboarding- en beheer-app en de SaaS-app zijn beide front-endtoepassingen. |
Workflow
De SaaS-klantbeheerder gaat naar de site die wordt gehost in de onboarding- en beheer-app.
De SaaS-klantbeheerder meldt zich aan met behulp van de aanmeldingswerkstroom van de gebruiker.
De SaaS-klantbeheerder voltooit de onboardingstroom.
De SaaS-klantbeheerder navigeert naar het tenantbeheerdersgebied in de onboarding- en beheer-app en voegt een SaaS-klantgebruiker toe aan de zojuist gemaakte tenant.
De SaaS-klantgebruiker navigeert naar de SaaS-toepassings-app en maakt gebruik van de SaaS-toepassing.
Gebruikersaanmelding
De aanmeldingswerkstroom van de gebruiker bestaat uit de volgende stappen:
De eindgebruiker navigeert naar een front-endtoepassing en selecteert een aanmeldingsknop.
De front-endtoepassing leidt de eindgebruiker om naar een aanmeldingspagina die wordt gehost door de id-provider.
De eindgebruiker voert accountgegevens in en verzendt het aanmeldingsformulier naar de id-provider.
De id-providergeeft een POST-aanvraag uit met het e-mailadres en de object-id van de eindgebruiker om hun machtigingen en rollen op te halen.
De API voor machtigingsgegevens zoekt de gegevens van de eindgebruiker op in de opslag van machtigingsgegevens en retourneert een lijst met machtigingen en rollen die aan die eindgebruiker zijn toegewezen.
De id-provider voegt de machtigingen en rollen toe als aangepaste claims aan het id-token, een JSON-webtoken (JWT).
De id-provider retourneert een id-token aan de eindgebruiker en initieert een omleiding naar de front-endtoepassing.
De eindgebruiker wordt omgeleid naar het aanmeldingseindpunt in de front-endtoepassing en geeft het id-token weer.
De front-endtoepassing valideert het gepresenteerde id-token.
De front-endtoepassing retourneert een geslaagde aanmeldingspagina en de eindgebruiker is nu aangemeld.
Zie OpenID Verbinding maken protocol voor meer informatie over de werking van deze aanmeldingsstroom.
Een nieuwe tenant onboarden
De onboardingwerkstroom van de tenant bestaat uit de volgende stappen:
De SaaS-klantbeheerder navigeert naar de onboarding- en beheer-app en vult een registratieformulier in.
De onboarding- en beheer-app geeft een POST-aanvraag uit aan de tenantgegevens-API om een nieuwe tenant te maken.
De tenantgegevens-API maakt een nieuwe tenant in de tenantgegevensopslag.
De tenantgegevens-API geeft een POST-aanvraag uit aan de API machtigingsgegevens om de SaaS-klantbeheerdersmachtigingen te verlenen aan de zojuist gemaakte tenant.
Met de API voor machtigingsgegevens wordt een nieuwe machtigingsrecord gemaakt in de opslag van machtigingsgegevens.
De API voor machtigingsgegevens wordt geretourneerd.
De TENANT-gegevens-API retourneert correct.
De onboarding- en beheer-app geeft een POST-aanvraag uit aan de e-mailmeldingsprovider om een e-mailbericht 'tenant gemaakt' te verzenden naar de SaaS-klantbeheerder.
De e-mailmeldingsprovider verzendt het e-mailbericht.
De e-mailmeldingsprovider wordt geretourneerd.
De onboarding- en beheer-app geeft een aanvraag uit aan de id-provider om het id-token van de SaaS-klantbeheerder te vernieuwen, zodat deze een JWT-claim bevat voor de zojuist gemaakte tenant.
De id-providergeeft een POST-aanvraag uit met het e-mailadres en de object-id van de SaaS-klantbeheerder om hun machtigingen en rollen op te halen.
De Api voor machtigingsgegevens zoekt de gegevens van de SaaS-klantbeheerder op in de opslag voor machtigingsgegevens en retourneert een lijst met machtigingen en rollen die zijn toegewezen aan de SaaS-klantbeheerder.
De id-provider voegt de machtigingen en rollen toe als aangepaste claims aan het id-token.
De id-provider retourneert het id-token naar de onboarding- en Beheer-app.
De onboarding- en beheer-app retourneert een geslaagd bericht en een nieuw id-token naar de SaaS-klant Beheer.
Een gebruiker toevoegen aan een tenant
De toevoeging van een gebruiker aan een tenantwerkstroom bestaat uit de volgende stappen:
De SaaS-klantbeheerder vraagt een lijst met tenants weer te geven vanuit het gebied tenantbeheerder in de onboarding - en beheer-app.
Met de onboarding- en beheer-app wordt een GET-aanvraag naar de tenantgegevens-API verzonden om een lijst met tenants op te halen voor de SaaS-klantbeheerder.
De TENANT-gegevens-API geeft een GET-aanvraag uit voor de MACHTIGINGsgegevens-API om een lijst op te halen met tenants waartoe de SaaS-klantbeheerder toegang heeft.
De API voor machtigingsgegevens retourneert een lijst met tenantmachtigingen.
De tenantgegevens-API zoekt de tenantgegevens op in de tenantgegevensopslag en retourneert een lijst met tenantgegevens op basis van de lijst met tenantmachtigingen die zijn ontvangen.
De onboarding- en beheer-app retourneert de lijst met tenantgegevens naar de SaaS-klantbeheerder.
De SaaS-klantbeheerder selecteert een tenant in de lijst om een SaaS-klantgebruiker toe te voegen aan en voert het e-mailadres in voor de SaaS-klantgebruiker.
De onboarding- en beheer-app geeft een POST-aanvraag uit aan de tenantgegevens-API om een machtiging toe te voegen voor de SaaS-klantgebruiker op de opgegeven tenant.
De tenantgegevens-API controleert of de SaaS-klantbeheerder een geldige JWT-claim heeft voor de opgegeven tenant en de schrijfmachtiging van de gebruiker heeft.
De tenantgegevens-API geeft een POST-aanvraag uit aan de API voor machtigingsgegevens om een machtiging toe te voegen voor de SaaS-klantgebruiker in de opgegeven tenant.
Met de API voor machtigingsgegevens wordt een GET-aanvraag naar de id-provider verzonden om de SaaS-klantgebruiker op te zoeken via het opgegeven e-mailadres.
De id-provider retourneert de object-id van de SaaS-klantgebruiker.
Met de API voor machtigingsgegevens wordt een machtigingsrecord toegevoegd in de machtigingsgegevensopslag voor de SaaS-klantgebruiker op de opgegeven tenant met behulp van hun object-id.
De API voor machtigingsgegevens wordt geretourneerd.
De TENANT-gegevens-API retourneert correct.
De onboarding- en beheer-app wordt geretourneerd.
Onderdelen
Deze architectuur maakt gebruik van de volgende Azure-services:
Met App Service kunt u web-apps en API-apps bouwen en hosten in de programmeertaal die u kiest zonder dat u infrastructuur hoeft te beheren.
Azure Active Directory B2C maakt identiteits- en toegangsbeheer eenvoudig mogelijk voor toepassingen van eindgebruikers.
Azure SQL Database is een relationele database voor algemeen gebruik die ondersteuning biedt voor relationele gegevens, ruimtelijke gegevens, JSON en XML.
Met Azure Logic Apps kunt u snel krachtige integraties bouwen met behulp van een eenvoudig GUI-hulpprogramma.
Alternatieven
De effectiviteit van alternatieve keuzes is sterk afhankelijk van het tenancymodel dat u voor uw SaaS-toepassing wilt ondersteunen. Hier volgen enkele voorbeelden van alternatieve benaderingen die u kunt volgen wanneer u deze oplossing implementeert:
De huidige oplossing maakt gebruik van Azure Active Directory B2C als id-provider. U kunt in plaats daarvan andere id-providers gebruiken, zoals Microsoft Entra-id.
Voor strengere beveiligings- en nalevingsvereisten kunt u ervoor kiezen om privénetwerken te implementeren voor communicatie tussen services.
In plaats van REST-aanroepen tussen services te gebruiken, kunt u een architectuurstijl op basis van gebeurtenissen implementeren voor berichten tussen services.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt volgen om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.
Deze oplossing is afhankelijk van identiteit als beveiligingsparadigma. Verificatie en autorisatie voor de web-apps en API's wordt beheerd door het Microsoft Identity Platform, dat verantwoordelijk is voor het uitgeven en verifiëren van tokens voor gebruikers-id's (JWT's).
Kostenoptimalisatie
Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.
De onderdelen in deze oplossing hebben een aantal kosten gekoppeld aan hun werking, maar de kosten zijn bescheiden voor de meeste webtoepassingen en SaaS-oplossingen. U kunt ook de kosten beheren door de volgende resource-instellingen te beheren:
U kunt het App Service-plan schalen waarmee de toepassing wordt uitgevoerd, zodat deze past bij de doorvoer die u nodig hebt. Bovendien kunt u elke app uitvoeren op een afzonderlijk plan als u een hogere doorvoer nodig hebt, maar er worden hogere kosten in rekening gebracht. Zie Azure-app serviceplanoverzicht voor meer informatie.
Azure AD B2C biedt twee SKU's: Premium P1 en Premium P2. Beide SKU's bevatten een gratis vergoeding voor het aantal maandelijkse actieve gebruikers (MAU's), maar u moet evalueren welke functies elke SKU biedt om te bepalen welke is vereist voor uw use-case. Zie Microsoft Entra Externe ID prijzen voor meer informatie.
Azure SQL heeft verschillende aankoopmodellen die passen bij een breed scala aan gebruiksvoorbeelden, waaronder de mogelijkheid om automatisch te schalen. U moet het gebruik van uw eigen databases evalueren om ervoor te zorgen dat u de grootte ervan correct instelt. Zie VCore- en DTU-aankoopmodellen van Azure SQL Database vergelijken voor meer informatie.
Prestatie-efficiëntie
Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie Overzicht van de pijler prestatie-efficiëntie voor meer informatie.
Deze architectuur moet kunnen worden geschaald om eenvoudig te voldoen aan de meeste middelgrote tot middelgrote workloads. Omdat de architectuur voornamelijk gebruikmaakt van PaaS-services (Platform) van Azure, hebt u veel opties om de schaal van de oplossing aan te passen op basis van uw vereisten en belasting.
Dit scenario implementeren
Als u dit scenario wilt implementeren, raadpleegt u de Azure SaaS Dev Kit op GitHub. Het is een implementeerbare referentie-implementatie van deze architectuur.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Landon Pierce | Klanttechnicus
Andere Inzenders:
- Chris Ayers | Senior klanttechnicus
- John Downs | Senior klanttechnicus
- LaBrina Loving | Principal SVC Engineering Manager
- Gary Moore | Programmeur/schrijver
- Nick Pinheiro | Senior Consultant
- William Salazar | Senior klanttechnicus
- Ali Sanjabi | Senior klanttechnicus
- Arsen Vladimirskiy | Principal Customer Engineer
- Jason Young | Principal SVC Engineering Manager
Volgende stappen
Hier volgen enkele aanvullende aanbevolen resources voor het bouwen van een SaaS-toepassing in Azure:
- Multitenant-oplossingen ontwerpen in Azure : beschrijft best practices.
- ISV-overwegingen voor Azure-landingszones
- Microsoft Azure Well-Architected Framework
- WingTips Tickets SaaS-toepassing - Biedt details over compromissen tussen verschillende tenancymodellen binnen de databaselaag.
Verwante resources
- Tenancymodellen om rekening mee te houden voor een multitenant-oplossing
- Architectuurbenaderingen voor compute in multitenant-oplossingen
- Architectuurbenaderingen voor opslag en gegevens in multitenant-oplossingen
- overwegingen voor Azure-app Service en Azure Functions voor multitenancy
- Multitenant SaaS in Azure
- Cloudontwerppatronen