Application web de démarrage pour le développement SaaS

Azure App Service

Microsoft Entra External ID

Azure SQL Database

Azure Logic Apps

Azure Resource Manager

Software as a Service (SaaS) est une rubrique complexe avec de nombreux points à prendre en compte. Les éditeurs de logiciels indépendants qui créent leurs solutions SaaS sur Azure doivent résoudre les problèmes et prendre des décisions telles que :

Quel modèle de location dois-je utiliser ?
Comment configurer une solution d’identité pour une utilisation dans une architecture mutualisée ?
Comment gérer l’intégration de nouveaux clients ?

Cette architecture vise à répondre à certaines de ces questions et à fournir un point de départ dans le monde de SaaS. Cette architecture peut s’adapter à un large éventail de scénarios.

Cas d’usage potentiels

Voici quelques exemples de cas d’utilisation dans lesquels vous pouvez utiliser cette architecture :

Moderniser une application existante pour prendre en charge une multilocataire complète dans le cadre d’un changement vers un modèle d’entreprise SaaS.
Développez une offre SaaS entièrement nouvelle.
Migrez une offre SaaS d’un autre service cloud vers Azure.

Architecture

Téléchargez un fichier PowerPoint de cette architecture.

Terminologie

Le tableau suivant décrit les termes qui apparaissent dans cet article.

Terme	Descriptif	Exemple
Éditeur SaaS ou éditeur de logiciels indépendants	Entité propriétaire de l’application SaaS et du code et vend le produit SaaS.	Contoso Inc qui vend son application SaaS : Contoso Tickets.
Locataire	Instance achetée de l’application SaaS auprès du fournisseur SaaS.	Quatrième café.
Administrateur client SaaS	Personne qui achète ou gère un locataire d’application.	Joe, propriétaire de Fourth Coffee Shop.
Utilisateur client de SaaS	Personne qui utilise un locataire d’application sans l’administrer et appartient généralement au même groupe ou société que l’administrateur client SaaS.	Jill, gestionnaire d’événements chez Fourth Coffee Shop et Susan, cliente de Fourth Coffee Shop.
Utilisateur final	Administrateur client SaaS, utilisateur client SaaS ou tout autre type d’utilisateur introduit. Il s'agit d'un terme générique pour décrire les utilisateurs qui se connectent à l'application.	Joe, Jill et Susan sont tous des utilisateurs finaux (du point de vue de l’ISV).
Application frontale	N’importe quelle application frontale.	L'application d'intégration et d'administration ainsi que l'application SaaS sont toutes deux des applications front-end.

Flux de travail

L’administrateur client SaaS accède au site hébergé sur l’application d’intégration et d’administration.
L’administrateur client SaaS se connecte à l’aide du flux de travail de connexion utilisateur.
L’administrateur client SaaS termine le flux d’intégration.
L’administrateur client SaaS accède à la zone d’administration du locataire sur l’application d’intégration et d’administration et ajoute un utilisateur client SaaS à son locataire nouvellement créé.
L’utilisateur client SaaS accède à l’application d’application SaaS et utilise l’application SaaS.

Le flux de travail de connexion de l’utilisateur se déroule comme suit :

L’utilisateur final accède à une application frontale et sélectionne un bouton Connexion.
L’application frontale redirige l’utilisateur final vers une page de connexion hébergée par le fournisseur d’identité.
L’utilisateur final entre les informations de compte et envoie le formulaire de connexion au fournisseur d’identité.
Le fournisseur d’identitéémet une requête POST avec l’adresse e-mail et l’ID d’objet de l’utilisateur final pour récupérer ses autorisations et rôles.
L’API De données d’autorisation recherche les informations de l’utilisateur final dans le stockage des données d’autorisation et retourne une liste d’autorisations et de rôles attribués à cet utilisateur final.
Le fournisseur d’identité ajoute les autorisations et les rôles en tant que revendications personnalisées au jeton d’ID, qui est un jeton web JSON (JWT).
Le fournisseur d’identité retourne un jeton d’ID à l’utilisateur final et lance une redirection vers l’application frontale.
L’utilisateur final est redirigé vers le point de terminaison de connexion sur l’application frontale et présente le jeton d’ID.
L’application frontale valide le jeton d’ID présenté.
L’application frontale retourne une page de connexion réussie et l’utilisateur final est maintenant connecté.

Pour plus d’informations sur le fonctionnement de ce flux de connexion, consultez le protocole OpenID Connect.

Intégrer un nouveau locataire

Le flux de travail d’intégration du locataire comprend les étapes suivantes :

L’administrateur client SaaS accède à l’application d’intégration et d’administration et termine un formulaire d’inscription.
L’application d’intégration et d’administration émet une requête POST à l’API de données client pour créer un locataire.
L’API de données du locataire crée un locataire dans le stockage de données du locataire.
L’API de données client émet une demande POST à l’API de données d’autorisation pour accorder aux administrateurs client SaaS des autorisations pour le locataire nouvellement créé.
L’API de données d’autorisation crée un enregistrement d’autorisation dans le stockage des données d’autorisation.
L’API de données d’autorisation retourne correctement.
L’API de données du locataire retourne correctement.
L’application d’intégration et d’administration émet une demande POST au fournisseur de notification par e-mail pour envoyer un message électronique « locataire créé » à l’administrateur client SaaS.
Le fournisseur de notifications par e-mail envoie l’e-mail .
Le fournisseur de notifications par e-mail retourne correctement.
L’application d’intégration et d’administration émet une demande adressée au fournisseur d’identité pour actualiser le jeton d’ID de l’administrateur client SaaS afin qu’elle inclue une revendication JWT au locataire nouvellement créé.
Le fournisseur d’identitéémet une requête POST avec l’adresse e-mail et l’ID d’objet de l’administrateur client SaaS pour récupérer leurs autorisations et rôles.
L’API de données d’autorisation recherche les informations de l’administrateur client SaaS dans le stockage des données d’autorisation et retourne une liste d’autorisations et de rôles attribués à l’administrateur client SaaS.
Le fournisseur d’identité ajoute les autorisations et les rôles en tant que revendications personnalisées au jeton d’ID.
Le fournisseur d’identité retourne le jeton d’ID à l’application d’intégration et d’administration.
L’application d’intégration et d’administration retourne un message de réussite et un nouveau jeton d’ID à l’administrateur client SaaS.

Pour ajouter un utilisateur à un locataire

L’ajout d’un utilisateur à un flux de travail locataire se compose des étapes suivantes :

L’administrateur client SaaS demande d’afficher la liste des locataires à partir de la zone d’administration du locataire sur l’application d’intégration et d’administration.
L’application d’intégration et d’administration émet une requête GET à l’API de données client pour obtenir la liste des locataires pour l’administrateur client SaaS.
L’API de données client émet une demande GET à l’API de données d’autorisation pour obtenir la liste des locataires auxquels l’administrateur client SaaS a accès.
L’API de données d’autorisation retourne une liste d’autorisations de locataire.
L’API de données du locataire recherche les informations du locataire dans le stockage des données du locataire et retourne une liste de données de locataire en fonction de la liste des autorisations de locataire reçues.
L’application d’intégration et d’administration retourne la liste des données de locataire à l’administrateur client SaaS.
L’administrateur client SaaS sélectionne un locataire dans la liste pour ajouter un utilisateur client SaaS et entrer l’adresse e-mail de l’utilisateur client SaaS.
L’application d’intégration et d’administration émet une requête POST à l’API de données client pour ajouter une autorisation pour l’utilisateur client SaaS sur le locataire spécifié.
L’API de données du locataire vérifie que l’administrateur client SaaS dispose d’une revendication JWT valide pour le locataire spécifié et dispose de l’autorisation d’écriture de l’utilisateur sur celle-ci.
L’API de données client émet une demande POST à l’API de données d’autorisation pour ajouter une autorisation pour l’utilisateur client SaaS sur le locataire spécifié.
L’API de données d’autorisation émet une demande GET au fournisseur d’identité pour rechercher l’utilisateur client SaaS par l’adresse e-mail fournie.
Le fournisseur d’identité retourne l’ID d’objet de l’utilisateur client SaaS.
L’API de données d’autorisation ajoute un enregistrement d’autorisation dans le stockage des données d’autorisation pour l’utilisateur client SaaS sur le locataire spécifié à l’aide de son ID d’objet.
L’API de données d’autorisation retourne correctement.
L’API de données du locataire retourne correctement.
L’application d’intégration et d’administration retourne correctement.

Composants

Cette architecture utilise les services Azure suivants :

App Service vous permet de créer et d’héberger des applications web et des applications API dans le langage de programmation que vous choisissez sans avoir à gérer l’infrastructure.
Azure Active Directory B2C permet facilement la gestion des identités et des accès pour les applications des utilisateurs finaux.
Azure SQL Database est un service managé de base de données relationnelle à usage général qui prend en charge les données relationnelles, les données spatiales, JSON et XML.
Azure Logic Apps vous permet de créer rapidement des intégrations puissantes à l’aide d’un outil d’interface utilisateur graphique simple.

Autres solutions

L’efficacité de tous les choix alternatifs dépend grandement du modèle de location que vous avez l’intention de prendre en charge pour votre application SaaS. Voici quelques exemples d’autres approches que vous pouvez suivre lorsque vous implémentez cette solution :

La solution actuelle utilise Azure Active Directory B2C comme fournisseur d’identité. Vous pouvez utiliser d’autres fournisseurs d’identité, tels que Microsoft Entra ID.
Pour des exigences de sécurité et de conformité plus strictes, vous pouvez choisir d’implémenter la mise en réseau privée pour la communication entre services.
Au lieu d’utiliser des appels REST entre les services, vous pouvez implémenter un style architectural piloté par les événements pour la messagerie interservices.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour la sécurité.

Cette solution s’appuie sur l’identité comme paradigme de sécurité. L’authentification et l’autorisation pour les applications web et les API sont régies par la plateforme d’identités Microsoft, qui est responsable de l’émission et de la vérification des jetons d’ID utilisateur (JWT).

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de contrôle de révision de conception pour l’optimisation des coûts.

Les composants de cette solution ont un certain coût de fonctionnement, mais ce coût est modeste pour la plupart des applications web et des solutions SaaS. En outre, vous pouvez contrôler le coût en gérant les paramètres de ressources suivants :

Vous pouvez adapter le plan de service de l'application qui exécute l'application pour correspondre au débit dont vous avez besoin. En outre, vous pouvez exécuter chaque application sur un plan distinct si vous avez besoin d’un débit plus élevé, mais vous aurez alors un coût plus élevé en conséquence. Pour plus d’informations, consultez la vue d’ensemble du plan Azure App Service.
Azure AD B2C fournit deux références SKU : Premium P1 et Premium P2. Ces deux références SKU incluent une allocation gratuite pour le nombre d’utilisateurs actifs mensuels (MAU), mais vous devez évaluer les fonctionnalités fournies par chaque référence pour déterminer quelles sont les conditions requises pour votre cas d’usage. Pour plus d’informations, consultez la tarification de Microsoft Entra External ID.
Azure SQL propose plusieurs modèles d’achat pour répondre à un large éventail de cas d’usage, notamment la possibilité de mettre à l’échelle automatiquement. Vous devez évaluer l’utilisation sur vos propres bases de données pour vous assurer de les dimensionner correctement. Pour plus d’informations, consultez Comparer les modèles d’achat vCore et DTU d’Azure SQL Database.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour l’efficacité des performances.

Cette architecture doit pouvoir être mise à l’échelle pour répondre facilement à la plupart des charges de travail moyennes et ou entre moyennes et larges. Étant donné que l'architecture utilise principalement les services de la plateforme Azure (plateforme en tant que service (PaaS)), vous disposez de nombreuses options pour ajuster l'échelle de la solution en fonction de vos exigences et de la charge.

Déployer ce scénario

Si vous souhaitez déployer ce scénario, consultez le Kit de développement Azure SaaS sur GitHub. Il s’agit d’une implémentation de référence déployable de cette architecture.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Landon Pierce | Ingénieur client

Autres contributeurs :

Chris Ayers | Ingénieur client senior
John Downs | Ingénieur client senior
LaBrina Loving | Principal SVC Engineering Manager
Gary Moore | Programmeur/enregistreur
Nick Pinheiro | Senior Consultant
William Salazar | Ingénieur client senior
Ali Sanjabi | Ingénieur client senior
Arsenal Vladimirskiy | Ingénieur client principal
Jason Young | Principal SVC Engineering Manager

Étapes suivantes

Voici quelques ressources recommandées supplémentaires pour créer une application SaaS sur Azure :

Concevoir des solutions multilocataires sur Azure : décrit les meilleures pratiques.
Considérations relatives aux éditeurs de logiciels indépendants pour les zones d’atterrissage Azure
Microsoft Azure Well-Architected Framework
Application WingTips Tickets SaaS : fournit des détails sur les compromis entre différents modèles de location au sein de la couche de base de données.

Partage via