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 | Description | 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. | Fourth Coffee Shop. |
| 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’administration et d’intégration ainsi que l’application SaaS sont les deux applications frontales. |
Workflow
L’administrateur client SaaS accède au site hébergé sur l’application d’administration et d’intégration.
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’administration et d’intégration puis ajoute un utilisateur client SaaS au locataire nouvellement créé.
L’utilisateur client SaaS accède à l’application SaaS et utilise l’application SaaS.
Connexion de l’utilisateur
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 de 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 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’administration et d’intégration et termine un formulaire d’inscription.
L’application d’administration et d’intégration émet une requête POST à l’API de données client pour créer un nouveau locataire.
L’API de données client 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’administration et d’intégration émet une requête POST au fournisseur de notification par e-mail pour envoyer un message électronique « locataire créé » à l’administrateur client SaaS.
Le fournisseur de notification par e-mail envoie l’e-mail.
Le fournisseur de notification par e-mail renvoie une confiormation.
L’application d’administration et d’intégration émet une demande au fournisseur d’identité pour actualiser le jeton d’ID de l’administrateur client SaaS afin qu’il inclue une revendication JWT pour le 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 ses autorisations et rôles.
L’API 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 à cet 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’administration et d’intégration.
L’application d’administration et d’intégration 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 de la zone d’administration du locataire sur l’application d’administration et d’intégration.
L’application d’administration et d’intégration é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 client recherche les informations de locataire dans le stockage de données client et retourne une liste de données de locataire en fonction de la liste des autorisations de locataire reçues.
L’application d’administration et d’intégration 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 entre l’adresse e-mail de l’utilisateur client SaaS.
L’application d’administration et d’intégration é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 client 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 celui-ci.
L’API de données du locataire é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 avec 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’administration et d’intégration retourne la bonne réponse.
Composants
Cette architecture utilise les services Azure suivants :
App Service vous permet de créer et d’héberger des applications web et API dans le langage de programmation de votre choix sans avoir à gérer l’infrastructure.
Azure Active Directory B2C facilite la gestion des identités et des accès pour les applications utilisateur finals.
Azure SQL Database est un service géré 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 de puissantes intégrations à l’aide d’un outil d’interface graphique simple.
Autres solutions
L’efficacité de tous les choix alternatifs dépend grandement du modèle de location que vous envisagez 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 aussi utiliser d’autres fournisseurs d’identité, comme 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 entre les services.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez suivre pour améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier 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 consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’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 mettre à l’échelle le plan App Service qui exécute l’application pour ajuster le 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 Vue d’ensemble des plans 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 d’ID externe Microsoft Entra.
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 est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’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 PaaS d’Azure, vous avez de nombreuses options pour ajuster l’échelle de la solution en fonction de vos besoins et de votre charge.
Déployer ce scénario
Si vous souhaitez déployer ce scénario, consultez le Kit de développement SaaS Azure 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 | Customer Engineer
Autres contributeurs :
- Chris Ayers | Ingénieur client senior
- John Downs | Senior Customer Engineer
- LaBrina Loving | Responsable principale de l’ingénierie SVC
- Gary Moore | Programmeur/rédacteur
- Nick Pinheiro | Consultant senior
- William Salazar | Ingénieur client senior
- Ali Sanjabi | Ingénieur client senior
- Arsen Vladimirskiy | Principal Customer Engineer
- Jason Young | Principal SVC Engineering Manager
Étapes suivantes
Voici quelques ressources recommandées supplémentaires pour créer une application SaaS sur Azure :
- Définir l’architecture de solutions mutualisées 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 SaaS WingTips Tickets : fournit des détails sur les compromis entre différents modèles de location au sein de la couche de base de données.
Ressources associées
- Modèles à prendre en compte pour une solution mutualisée
- Approches architecturales pour le calcul dans les solutions multilocataires
- Approches architecturales en matière de stockage et de données dans les solutions multi-locataires
- Considérations relatives à Azure App Service et à Azure Functions pour l’architecture mutualisée
- SaaS mutualisé sur Azure
- Modèles de conception cloud