Le guide ultime pour configurer l'authentification et l'autorisation multi-locataires

Construire une application multi-locataires peut être un défi, avec de nombreux aspects à considérer. Cet article compile tous nos articles de blog précédents sur la compréhension des pratiques multi-locataires et organisationnelles. Pour un démarrage rapide et pour gagner du temps, consultez simplement cet article, il contient tout ce dont vous avez besoin !

Les directives générales sont décrites dans les étapes suivantes :

1. Comprendre l'architecture multi-locataires
2. Cartographier vos cas d'utilisation de l'application multi-locataires
3. Atteindre l'isolement des locataires
4. Définir comment vous souhaitez gérer les identités
5. Choisir les modèles d'autorisation appropriés

Qu'est-ce que l'architecture multi-locataires#

La multi-location logicielle est une architecture logicielle dans laquelle une seule instance de logiciel s'exécute sur un serveur et dessert 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 qui partagent un accès commun avec des privilèges spécifiques à l'instance logicielle.

L'un des aspects clés de la multi-location est le concept de "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é. Plutôt, cela signifie qu'au moins certains composants d'une solution sont réutilisés à travers plusieurs locataires. Comprendre ce terme dans un sens large peut mieux vous aider à empathiser avec les besoins de votre client et d'où ils viennent.

Une fois que vous comprenez l'architecture multi-locataires, l'étape suivante consiste à appliquer votre application à des scénarios réels, en vous concentrant sur les besoins spécifiques du produit et de l'entreprise.

Quels sont les cas d'utilisation pour les applications multi-locataires ?#

Multi-locataires dans le SaaS#

Les applications multi-locataires trouvent souvent leur place dans les solutions entreprise à entreprise (B2B) comme les outils de productivité, les logiciels de collaboration et autres produits software-as-a-service (SaaS). Dans ce contexte, chaque "locataire" représente généralement un client d'affaires, qui pourrait avoir plusieurs utilisateurs (ses employés). En outre, un client d'affaires pourrait avoir plusieurs locataires pour représenter des organisations ou divisions commerciales distinctes.

Multi-locataires dans des cas d'utilisation B2B génériques#

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 plate-forme commune pour que diverses équipes, clients commerciaux et entreprises partenaires accèdent à vos applications.

Par exemple, considérez une entreprise de covoiturage qui fournit des applications B2C et B2B. Les applications B2B desservent plusieurs clients commerciaux, et l'utilisation d'une architecture multi-locataires peut aider à gérer leurs employés et ressources. Pour illustrer, si l'entreprise souhaite maintenir un système d'identité utilisateur unifié, elle peut concevoir une architecture comme l'exemple suivant :

Sarah a à la fois une identité personnelle et une identité d'entreprise. Elle utilise le service de covoiturage en tant que passagère et travaille également comme conductrice durant son temps libre. Dans son rôle professionnel, elle gère également son entreprise et utilise cette identité d'entreprise pour être partenaire avec Entreprise 1.

Pourquoi devriez-vous utiliser la multi-location dans les produits SaaS#

Evolutivité avec la multi-location#

Pour les entreprises de grande taille, la multi-location est la clé pour satisfaire efficacement leurs exigences en matière de disponibilité, gestion des ressources, gestion des coûts et sécurité des données. Sur un plan technique, adopter une approche multi-locataires rationalise vos processus de développement, minimise les défis techniques et favorise une expansion fluide.

Créer une expérience unifiée#

Lorsque l'on examine les racines des produits SaaS, cela ressemble à un bâtiment abritant divers appartements. Tous les locataires partagent des services communs comme l'eau, l'électricité et le gaz, mais ils conservent un contrôle indépendant sur la gestion de leur propre espace et ressources. Cette approche simplifie la gestion de la propriété.

Assurer la sécurité par l'isolement des locataires#

Dans une architecture multi-locataires, le terme "locataire" est introduit pour créer des frontières qui séparent et sécurisent les ressources et les données des différents locataires au sein d'une instance partagée. Cela garantit que les données et les opérations de chaque locataire restent distinctes et sûres, même s'ils utilisent les mêmes ressources sous-jacentes.

Pourquoi devez-vous réaliser l'isolement des locataires ?#

Lorsqu'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 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 atteindre l'isolement des locataires.

L'isolement des locataires ne va pas à l'encontre de la mentalité "partagée" de la multi-location#

C'est parce que l'isolement des locataires n'est pas nécessairement une construction au niveau des ressources 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, des instances de calcul, des comptes ou des clouds privés séparés. Dans les scénarios de ressources partagées, comme les applications multi-locataires, la façon d'atteindre 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 à "isolement"#

Utiliser l'authentification et l'autorisation pour contrôler l'accès à vos environnements SaaS est important, mais ce n'est pas suffisant pour un isolement complet. Ces mécanismes ne sont qu'une partie du puzzle de sécurité.

Les gens posent souvent la question : puis-je utiliser des solutions d'autorisation générales et le contrôle d'accès basé sur les rôles pour atteindre l'isolement des locataires ?

Voici le problème, vous pouvez créer une application multi-locataires, mais vous ne pouvez pas dire que vous avez atteint et employé des stratégies d'isolement des locataires comme une meilleure pratique. Nous ne le recommandons généralement pas parce que

Pour illustrer, considérez une situation où vous avez configuré l'authentification et l'autorisation pour votre système SaaS. Lorsqu'un utilisateur se connecte, il reçoit un jeton contenant des informations sur son rôle, indiquant ce qu'il peut faire dans l'application. Cette approche améliore la sécurité mais ne garantit pas l'isolement.

Utilisez "organisation" pour représenter le locataire du produit SaaS, pour atteindre l'isolement des locataires#

Se fier uniquement à l'authentification et l'autorisation ne peut empêcher un utilisateur avec le bon rôle d'accéder aux ressources d'un autre locataire. Nous devons donc incorporer un contexte de "locataire", tel qu'un ID de locataire, pour restreindre l'accès aux ressources.

C'est ici que l'isolement des locataires entre en jeu. Il utilise des identifiants spécifiques aux locataires pour établir des limites, à l'instar de murs, portes, et serrures, assurant une séparation claire entre les locataires.

Gestion des 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écidez-vous si vos identités doivent être "isolées" ou non ?

Il y a souvent une confusion autour du concept d'"isolement des identités". 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é ainsi qu'un e-mail d'entreprise connecté via une authentification unique (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 séparés. Ces produits ne sont pas du tout liés entre eux.

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 d'un "isolement des identités", considérez

Cette réponse peut guider votre conception de système. Pour une réponse brève concernant une application multi-locataires,

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 du bâtiment ; vous ne voudriez pas maintenir deux listes de noms séparées pour gérer les identités de vos locataires.

En recherchant l'isolement des locataires, vous avez peut-être observé l'accent récurrent mis sur le terme "organisation", souvent considéré comme une meilleure pratique pour construire des applications multi-locataires.

En utilisant 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é.

Comment choisir et concevoir le modèle d'autorisation approprié#

Lors de la sélection du modèle d'autorisation approprié, considérez ces questions :

1. Développez-vous un produit B2C, B2B ou une combinaison des deux types de produits ?
2. Votre application a-t-elle une architecture multi-locataires ?
3. Y a-t-il un besoin d'un certain niveau d'isolement dans votre application, tel que déterminé par l'unité de l'entreprise ?
4. Quelles permissions et rôles doivent être définis dans le contexte de l'organisation, et lesquels ne le sont pas ?

Quels modèles d'autorisation différents sont disponibles dans Logto ?#

Contrôle d'accès basé sur les rôles#

Le contrôle d'accès basé sur les rôles (RBAC) est une méthode pour accorder des permissions aux utilisateurs en fonction de leurs rôles, permettant une gestion efficace de l'accès aux ressources.

Cette technique courante sous-tend le contrôle d'accès et est un composant clé des fonctionnalités d'autorisation de Logto. En tant que plate-forme complète de gestion des identités, Logto offre des solutions sur mesure pour divers niveaux et entités, répondant aux besoins des développeurs et des entreprises pour des architectures de produits variées.

Contrôle d'accès basé sur les rôles API#

Pour protéger les ressources API générales qui ne sont spécifiques à aucune organisation et n'ont pas besoin de restrictions contextuelles, la fonctionnalité API RBAC est idéale.

Il suffit d'enregistrer l'API et d'attribuer des permissions à chaque ressource. Ensuite, contrôlez l'accès à travers la relation entre les rôles et les utilisateurs.

Les ressources API, rôles, et permissions ici sont "démocratisés" sous un système d'identité unifié. C'est assez courant dans les produits B2C avec moins de hiérarchie et n'ayant pas besoin d'un niveau d'isolement très profond.

Contrôle d'accès basé sur les rôles organisationnels#

Dans l'environnement B2B et multi-locataires, l'isolement des locataires est nécessaire. Pour y parvenir, les organisations sont utilisées comme un contexte pour l'isolement, ce qui signifie que le RBAC est efficace uniquement lorsqu'un utilisateur appartient à une organisation spécifique.

Le RBAC organisationnel se concentre sur le contrôle d'accès au niveau de l'organisation plutôt qu'au niveau de l'API. Cela offre une flexibilité significative pour l'auto-gestion au niveau de l'organisation sur le long terme, mais toujours au sein d'un système d'identité unifié.

Une caractéristique clé du RBAC organisationnel est que les rôles et permissions sont généralement les mêmes par défaut dans toutes les organisations, 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 identités sont des composants d'infrastructure communs à tous les locataires (locataires d'application), une pratique courante dans les produits SaaS.

Conclusion#

Cet article vous fournit tout ce dont vous avez besoin pour commencer à préparer et configurer des applications multi-locataires. Essayez Logto aujourd'hui et commencez à appliquer les meilleures pratiques pour le développement d'applications multi-locataires avec des organisations.