Français

multi-location
saas
organisation
collaboration
identité
contrôle d'accès

Le modèle de multi-location de Logto expliqué

Jetez un œil à la façon dont nous avons conçu le modèle de multi-location de Logto et aux avantages qu'il apporte aux applications SaaS.

Gao

Founder

11/29/2023

Arrêtez de perdre des semaines sur l'authentification des utilisateurs

Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.

Commencer

La confusion

Vous avez peut-être entendu parler de certains produits qui utilisent le terme "multi-location" pour représenter l'isolation des identités : chaque locataire a son propre ensemble d'utilisateurs, de rôles, de permissions et de données.

Cela peut sembler contre-intuitif, mais en fait, "multi-location" indique le contraire : plusieurs locataires partagent des ressources dans une seule instance. Pour les utilisateurs, une identité dans une application est comme un permis de conduire. Par exemple, avec un permis de conduire, vous pouvez conduire dans différents états (une identité pour plusieurs organisations), au lieu de demander un nouveau permis de conduire pour chaque état.

Le modèle de Logto

Chez Logto, nous avons remarqué cette confusion dès le début de notre conception, et nous nous sommes efforcés de le rendre correct pour vos applications et vos utilisateurs. Voici notre conception :

Un locataire peut être traité comme une instance Logto unique, qui possède son propre ensemble d'utilisateurs, de permissions et de données.
Au sein d'un locataire, il peut y avoir plusieurs organisations. Un utilisateur peut être membre de plusieurs organisations.
Pour chaque organisation, elle suit le modèle de contrôle d'accès basé sur les rôles (RBAC) et utilise le même ensemble de rôles organisationnels et de permissions organisationnelles. Cet ensemble est appelé modèle d'organisation.
Les rôles organisationnels et les permissions organisationnelles sont effectifs uniquement dans le contexte d'une organisation.
- Par exemple, un utilisateur peut être "admin" (rôle) dans une organisation, mais "membre" (rôle) dans une autre organisation.
- Sans le contexte d'une organisation, les rôles organisationnels et les permissions organisationnelles sont dénués de sens.
Utilisez les permissions organisationnelles pour contrôler l'accès dans une organisation, au lieu d'utiliser les rôles organisationnels.

Ce modèle offre la flexibilité et la réutilisabilité pour la gestion des identités, en particulier pour les applications SaaS. Si nous regardons certaines applications SaaS populaires, nous pouvons constater qu'elles peuvent toutes s'intégrer dans ce modèle. Le terme "organisation" peut être différent dans différentes applications, telles que "espace de travail", "équipe", etc. Mais le concept est le même.

Par exemple, dans Notion (un outil de collaboration populaire) :

Vous pouvez créer et rejoindre plusieurs espaces de travail avec un seul compte, au lieu de vous inscrire à chaque espace de travail avec des comptes différents.
Pour chaque espace de travail, Notion définit un même ensemble de niveaux d'accès : "propriétaire de l'espace de travail" et "membre", alors que vous pourriez vous attendre à des niveaux d'accès différents pour différents espaces de travail.

Ainsi, les utilisateurs peuvent facilement passer d'un espace de travail à un autre sans changer de compte ou se reconnecter, tout en maintenant l'isolation entre les espaces de travail. Traduisons cela au modèle de Logto, cela signifie :

Le modèle d'organisation définit deux rôles : "propriétaire" et "membre".
Si un utilisateur a rejoint un espace de travail, cela signifie que l'utilisateur est membre d'une organisation, et qu'il a le rôle de "membre" dans l'organisation.
Si un utilisateur a créé un espace de travail, cela signifie que l'utilisateur est membre d'une organisation, et qu'il a le rôle de "propriétaire" dans l'organisation.

En fonction des rôles différents, un utilisateur peut avoir des permissions différentes dans différents espaces de travail (organisations).

Les avantages

Expérience utilisateur

Pour les utilisateurs, ils peuvent profiter d'une véritable expérience de connexion unique. Passer d'une organisation à une autre est aussi simple que de passer d'un onglet à un autre.

Réutilisabilité

Un avantage des applications SaaS est qu'elles sont standardisées et évolutives. Par exemple, vous pouvez créer un nouvel espace de travail dans Notion en quelques clics, et il est prêt à être utilisé.

Lorsque votre application se développe, vous pouvez vouloir ajouter plus de rôles et de permissions à chaque organisation. Par exemple, un nouveau rôle "invité" et une nouvelle permission "inviter:invité". Cela peut devenir un cauchemar si vous devez mettre à jour toutes les organisations existantes une par une.

Avec Logto, vous pouvez mettre à jour le modèle d'organisation, et toutes les organisations existantes seront mises à jour automatiquement.

Un seul modèle de contrôle d'accès, plusieurs cas d'utilisation

Chez Logto, nous utilisons le même modèle de contrôle d'accès (RBAC) pour les organisations et les ressources API. Cela signifie que vous n'avez pas besoin d'apprendre un nouveau modèle de contrôle d'accès si vous êtes familier avec le RBAC. Parallèlement, ils sont isolés les uns des autres, vous pouvez donc les utiliser pour différents cas d'utilisation.

La partie la plus excitante est que vous pouvez les utiliser en même temps. Poussons l'exemple de Notion un peu plus loin :

Pour accéder aux espaces de travail, vous pouvez utiliser le RBAC organisationnel de Logto.
Pour accéder et mettre à jour les ressources au niveau du compte (par exemple, le profil et les informations de facturation), vous pouvez utiliser le RBAC des ressources API de Logto.

La plupart des SDK de Logto prennent en charge les deux types de RBAC.

Les différences

Le RBAC organisationnel et le RBAC des ressources API sont différents dans les aspects suivants :

Le RBAC organisationnel nécessite le contexte d'une organisation, alors que le RBAC des ressources API n'en a pas besoin.
Le RBAC organisationnel est utilisé pour contrôler l'accès dans une organisation, tandis que le RBAC des ressources API est utilisé pour contrôler l'accès aux ressources API.
Un utilisateur peut avoir différents rôles organisationnels dans différentes organisations, alors que les rôles pour les ressources API sont universels dans le locataire.
Les rôles et les permissions sont isolés pour ces deux types de RBAC.

Notes de fin

Construire une application SaaS est difficile, et nous espérons que Logto peut vous aider à vous concentrer sur votre cœur de métier. N'hésitez pas à nous faire part de vos commentaires si vous avez des questions ou des suggestions.

Essayez Logto Cloud gratuitement

La confusion#

Le modèle de Logto#

Les avantages#

Expérience utilisateur#

Réutilisabilité#

Un seul modèle de contrôle d'accès, plusieurs cas d'utilisation#

Notes de fin#

La confusion#

Le modèle de Logto#

Les avantages#

Expérience utilisateur#

Réutilisabilité#

Un seul modèle de contrôle d'accès, plusieurs cas d'utilisation#

Notes de fin#

La confusion

Le modèle de Logto

Les avantages

Expérience utilisateur

Réutilisabilité

Un seul modèle de contrôle d'accès, plusieurs cas d'utilisation

Notes de fin

La confusion

Le modèle de Logto

Les avantages

Expérience utilisateur

Réutilisabilité

Un seul modèle de contrôle d'accès, plusieurs cas d'utilisation

Notes de fin