Créer une application multi-locataires peut être un défi, avec de nombreux aspects à considérer. Cet article compile tous nos anciens articles de blog sur la compréhension des pratiques multi-locataires et d'organisation. Pour un démarrage rapide et pour gagner du temps, consultez simplement cet article, il inclut tout ce dont vous avez besoin ! Les lignes directrices générales sont présentées dans les étapes suivantes : 1. Comprendre l'architecture multi-locataires 2. Cartographier les cas d'utilisation de votre application multi-locataires 3. Réaliser l'isolement des locataires 4. Définir comment vous souhaitez gérer les identités 5. Choisir les modèles d'autorisation appropriés ## Comprendre l'architecture multi-locataires La multi-location logicielle est une [architecture logicielle](https://fr.wikipedia.org/wiki/Architecture_logicielle) dans laquelle une seule [instance](https://fr.wikipedia.org/wiki/Instance_(informatique)) de [logiciel](https://fr.wikipedia.org/wiki/Logiciel) fonctionne sur un serveur et sert plusieurs locataires. Les systèmes conçus de cette manière sont "partagés" (plutôt que "dédiés" ou "isolés"). Un locataire est un groupe d'utilisateurs partageant un accès commun avec des privilèges spécifiques à l'instance logicielle. multi-locataire

L'un des concepts clés de la multi-location est "partagé". Dans la définition plus large de la multi-location, être une application multi-locataires ne signifie pas que **chaque** composant d'une solution est partagé. Au contraire, cela implique qu'au moins **certains** composants d'une solution sont réutilisés par plusieurs locataires. Comprendre ce terme de façon large peut vous aider à mieux comprendre les besoins de vos clients et d'où ils viennent. Une fois que vous avez compris l'architecture multi-locataires, l'étape suivante est d'appliquer votre application à des scénarios réels, en vous concentrant sur des besoins spécifiques de produits et d'affaires. ## Cartographier les cas d'utilisation de votre application multi-locataires ### SaaS Les applications multi-locataires trouvent souvent leur place dans les solutions business-to-business (B2B) comme les outils de productivité, les logiciels de collaboration et autres produits de software-as-a-service (SaaS). Dans ce contexte, chaque "locataire" représente généralement un client commercial, qui pourrait avoir plusieurs utilisateurs (ses employés). De plus, un client commercial pourrait avoir plusieurs locataires pour représenter des organisations ou divisions commerciales distinctes. ![SaaS](https://uploads.strapi.logto.io/1/saas_product_d63c736650.webp) ### Cas d'utilisation générique B2B Les applications B2B vont au-delà des produits SaaS et impliquent souvent l'utilisation d'applications multi-locataires. Dans les contextes B2B, ces applications servent de plateforme commune pour divers équipes, clients commerciaux et entreprises partenaires pour accéder à vos applications. Par exemple, considérez une entreprise de covoiturage qui fournit à la fois des applications B2C et B2B. Les applications B2B servent plusieurs clients commerciaux, et utiliser une architecture multi-locataires peut aider à la gestion de leurs employés et ressources. Pour illustrer, si l'entreprise souhaite maintenir un système d'identité d'utilisateur unifié, elle peut concevoir une architecture comme l'exemple suivant : Sarah possède à la fois une identité personnelle et une identité professionnelle. Elle utilise le service de covoiturage en tant que passagère et travaille également en tant que conductrice pendant son temps libre. Dans son rôle professionnel, elle gère également son entreprise et utilise cette identité professionnelle pour être partenaire avec Business 1.

carte d'identité d'utilisateur et de rôle

### Pourquoi devez-vous utiliser la multi-location dans un produit SaaS #### Evoluer avec la multi-location Pour les entreprises, la multi-location est la clé pour répondre efficacement à leurs exigences de disponibilité, de gestion des ressources, de gestion des coûts et de sécurité des données. Sur le plan technique, adopter une approche multi-locataires rationalise vos processus de développement, minimise les défis techniques et favorise une expansion transparente. #### Créer une expérience unifiée En examinant les racines des produits SaaS, c'est akin à un bâtiment hébergeant divers appartements. Tous les locataires partagent des utilitaires communs comme l'eau, l'électricité et le gaz, tout en gardant un contrôle indépendant sur la gestion de leur propre espace et ressources. Cette approche simplifie la gestion immobilière. #### Assurer la sécurité par l'isolement des locataires Dans une architecture multi-locataires, le terme "locataire" est introduit pour créer des limites qui séparent et sécurisent les ressources et les données de différents locataires au sein d'une instance partagée. Cela garantit que les données et opérations de chaque locataire restent distinctes et sécurisées, même s'ils utilisent les mêmes ressources sous-jacentes. ## Réaliser l'isolement des locataires Lorsque l'on discute des applications multi-locataires, il est toujours nécessaire de réaliser **l'isolement des locataires**. Cela signifie garder les données et les ressources des différents locataires séparées et sécurisées au sein d'un système partagé (par exemple, une infrastructure cloud ou une application multi-locataires). Cela empêche toute tentative non autorisée d'accéder aux ressources d'un autre locataire. Bien que l'explication puisse sembler abstraite, nous utiliserons des exemples et des détails clés pour expliquer davantage la mentalité d'isolement et la meilleure pratique pour parvenir à l'isolement des locataires. ### L'isolement des locataires ne va pas à l'encontre de la mentalité "partagée" de la multi-location Cela est dû au fait que l'isolement des locataires n'est pas nécessairement une construction de niveau ressource d'infrastructure. Dans le domaine de la multi-location et de l'isolement, certains considèrent l'isolement comme une division stricte entre les ressources d'infrastructure réelles. Cela conduit généralement à un modèle où chaque locataire a des bases de données séparées, des instances de calcul, des comptes ou des nuages privés. Dans les scénarios de ressources partagées, comme les applications multi-locataires, le moyen d'obtenir l'isolement peut être une construction logique. L'isolement des locataires se concentre exclusivement sur l'utilisation du contexte "locataire" pour limiter l'accès aux ressources. Il évalue le contexte du locataire actuel et utilise ce contexte pour déterminer quelles ressources sont accessibles pour ce locataire. ### L'authentification et l'autorisation ne sont pas égales à l'"isolement" L'utilisation de l'authentification et de l'autorisation pour contrôler l'accès à vos environnements SaaS est importante, mais elle n'est pas suffisante pour un isolement complet. Ces mécanismes ne sont qu'une partie du puzzle de la sécurité. Les gens posent souvent une question, puis-je utiliser des solutions d'autorisation générales et de contrôle d'accès basé sur les rôles pour atteindre l'isolement des locataires ? Voici la chose, vous pouvez construire une application multi-locataires mais vous ne pouvez pas dire que vous avez atteint et appliqué les stratégies d'isolement des locataires en tant que meilleure pratique. Nous ne le recommandons généralement pas parce que L'isolement des locataires est distinct de l'authentification et de l'autorisation. Pour illustrer, considérez une situation où vous avez configuré l'authentification et l'autorisation pour votre système SaaS. Lorsque les utilisateurs se connectent, ils reçoivent un jeton contenant des informations sur leur rôle, dictant ce qu'ils peuvent faire dans l'application. Cette approche améliore la sécurité mais n'assure pas l'isolement. ### Utiliser "organisation" pour représenter le locataire de produit SaaS, pour réaliser l'isolement des locataires Se fier uniquement à l'authentification et à l'autorisation ne permettra pas d'empêcher un utilisateur avec le bon rôle d'accéder aux ressources d'un autre locataire. Nous devons donc incorporer un contexte "locataire", tel qu'un identifiant de locataire, pour restreindre l'accès aux ressources. C'est là que l'isolement des locataires entre en jeu. Il utilise des identifiants spécifiques aux locataires pour établir des frontières, comme des murs, des portes et des serrures, garantissant une séparation claire entre les locataires. ## Identités dans les applications multi-locataires Nous avons discuté de l'isolement des locataires, mais qu'en est-il des identités ? Comment décider si vos identités doivent être "isolées" ou non ? Il y a souvent de la confusion autour du concept d'"isolement de l'identité". Cela pourrait faire référence à des situations où un utilisateur réel a deux identités dans la compréhension générale des gens. 1. Les deux identités peuvent exister au sein d'un système d'identité unique. Par exemple, Sarah pourrait avoir un e-mail personnel enregistré aux côtés d'un e-mail professionnel connectés via single sign-on (SSO). 2. Les utilisateurs maintiennent deux identités distinctes au sein de systèmes d'identité séparés, représentant des produits entièrement distincts. Ces produits sont complètement sans rapport les uns avec les autres. Parfois, ces scénarios sont appelés "identité isolée". Pourtant, cette étiquette pourrait ne pas aider à prendre une décision. Plutôt que de déterminer si vous avez besoin de "l'isolement de l'identité", considérez si vous ou un segment de votre entreprise ou produit devez maintenir des systèmes d'identité séparés Cette réponse peut guider la conception de votre système. Pour une réponse brève concernant une application multi-locataires, Dans la plupart des cas, dans les applications multi-locataires, les identités sont partagées tandis que les ressources de chaque locataire sont isolées. Dans les applications multi-locataires, les identités, contrairement aux ressources et données spécifiques aux locataires, sont partagées entre plusieurs locataires. Imaginez-vous en tant qu'administrateur de l'immeuble ; vous ne voudriez pas maintenir deux listes de noms distinctes pour gérer les identités de vos locataires. Lorsque vous visez l'isolement des locataires, vous avez peut-être observé l'emphase récurrente sur le terme "organisation", souvent considéré comme une meilleure pratique pour construire des applications multi-locataires. En employant la notion d'"organisation", vous pouvez atteindre l'isolement des locataires dans votre application multi-locataires tout en maintenant un système d'identité unifié. ## Choisir les modèles d'autorisation pour un meilleur contrôle d'accès ### Choisir et concevoir le modèle d'autorisation approprié Lors du choix du bon modèle d'autorisation, considérez ces questions : 1. Développez-vous un produit B2C, B2B ou une combinaison des deux ? 2. Votre application a-t-elle une architecture multi-locataires ? 3. Existe-t-il un besoin pour un certain niveau d'isolement dans votre application, tel que déterminé par l'unité commerciale ? 4. Quelles permissions et quels rôles doivent être définis dans le contexte de l'organisation et lesquels ne le sont pas ? ### Comprendre les différents modèles d'autorisation dans Logto #### Contrôle d'accès basé sur les rôles RBAC (Role-Based Access Control) est une méthode pour accorder des permissions aux utilisateurs basées sur leurs rôles, permettant une gestion efficace de l'accès aux ressources. Cette technique courante est à la base du contrôle d'accès et est une composante clé des fonctionnalités d'autorisation de Logto. En tant que plateforme de gestion d'identité complète, Logto offre des solutions adaptées à divers niveaux et entités, répondant aux besoins des développeurs et des entreprises pour des architectures de produits diversifiées. #### Contrôle d'accès basé sur les rôles pour API Pour protéger les ressources d'API générales qui ne sont spécifiques à aucune organisation et qui n'ont pas besoin de restrictions de contexte, la fonctionnalité **_API RBAC_** est idéale. Enregistrez simplement l'API et assignez des permissions à chaque ressource. Ensuite, contrôlez l'accès par la relation entre les rôles et les utilisateurs. Les ressources, rôles et permissions d'API ici sont "démocratisées" sous un système d'identité unifié. Cela est assez courant dans le produit B2C avec moins de hiérarchie et ne nécessitant pas un niveau très profond d'isolement. #### Contrôle d'accès basé sur les rôles pour l'organisation Dans l'environnement B2B et multi-locataires, l'isolement des locataires est nécessaire. Pour y parvenir, les organisations sont utilisées comme contexte pour l'isolement, signifiant que le RBAC est effectif seulement lorsqu'un utilisateur appartient à une organisation spécifique. L'Organisation RBAC se concentre sur le contrôle de l'accès au niveau de l'organisation plutôt qu'au niveau de l'API. Cela offre une flexibilité considérable pour l'auto-gestion au niveau de l'organisation à long terme mais toujours au sein d'un système d'identité unifié. Une caractéristique clé de l'Organisation RBAC est que les rôles et les permissions sont généralement les mêmes pour toutes les organisations par défaut, ce qui rend le "modèle d'organisation" de Logto extrêmement significatif pour améliorer l'efficacité du développement. Cela s'aligne avec la philosophie partagée des applications multi-locataires, où les politiques de contrôle d'accès et les identités sont des composants d'infrastructure communs pour tous les locataires (locataires d'applications), une pratique courante dans les produits SaaS. ## Conclusion Cet article vous fournit tout ce dont vous avez besoin pour vous lancer dans la préparation et la configuration des applications multi-locataires. Essayez Logto dès aujourd'hui et commencez à appliquer les meilleures pratiques pour le développement d'applications multi-locataires avec des organisations. Essayez Logto Cloud gratuitement