Étude de cas : Construire une multi-location avec Logto Organizations
Apprenez à mettre en place une base d'identité solide et évolutive pour la multi-location avec Logto Organizations.
De nos jours, la multi-location devient une partie essentielle d'une application ou d'un SaaS. Cela implique souvent une relation complexe entre les utilisateurs, les organisations, les rôles et les permissions. Par exemple, un utilisateur peut être membre de plusieurs organisations, et vice versa ; un utilisateur peut également avoir différents rôles dans différentes organisations.
Le problème
Cela peut entraîner des maux de tête non seulement au début, mais aussi pour la maintenance à long terme d'une application. Le modèle de contrôle d'accès basé sur les rôles (RBAC) traditionnel peut partiellement résoudre ce problème, mais devient rapidement un cauchemar lorsque le nombre d'utilisateurs et d'organisations augmente.
Par exemple, au début, vous pouvez n'avoir que deux rôles dans chaque organisation : admin
et member
. Lorsque vous avez 10 organisations, vous gérez 20 rôles ; lorsque vous avez 1 000 organisations, vous gérez 2 000 rôles.
À mesure que l'entreprise se développe, vous pouvez avoir besoin d'ajouter plus de rôles, tels que guest
, developer
, etc. La complexité du modèle RBAC augmentera de manière exponentielle.
Nous avons rencontré le même problème lorsque nous avons construit Logto Cloud. Nous avons vite réalisé que c'est un problème commun dans l'industrie, et que nous devons le résoudre. Et Logto Organizations est là pour sauvetager.
Modèle d'organisation
Une petite question : pourquoi les applications SaaS sont-elles des SaaS ? Nous croyons que la scalabilité est l'une des raisons les plus importantes. En d'autres termes, ce qui fonctionne pour un client devrait fonctionner pour tous les clients.
Cela conduit au concept de "modèle d'organisation". Un modèle d'organisation est un plan du modèle de contrôle d'accès pour chaque organisation : il définit les rôles et les permissions qui s'appliquent à toutes les organisations.
Disons que nous avons deux rôles pour chaque organisation :
admin
: peut gérer l'organisation, y compris ajouter / supprimer des membres, changer les rôles, etc.member
: peut accéder aux ressources de l'organisation et inviter de nouveaux membres.
Nous pouvons créer un modèle d'organisation avec la configuration suivante :
Ajouter des utilisateurs aux organisations
Puisque nous avons configuré le modèle d'organisation, la gestion des utilisateurs devient simple et naturelle. Vous pouvez ajouter un utilisateur à une organisation via Logto Console (l'interface web) ou via l'API de gestion de Logto
Voir Configurer les organisations pour en savoir plus.
Nous avons ajouté deux organisations avec la configuration suivante :
- Organisation A : Alice et Bob sont tous deux membres. Alice a le rôle
admin
, et Bob a le rôlemember
. - Organisation B : Seule Alice est membre, et elle a le rôle
member
.
Demander des jetons d'organisation dans votre application
Dans votre application cliente, vous pouvez maintenant demander un jeton d'accès à l'organisation (jeton d'organisation) de Logto. Le jeton d'organisation est un jeton JWT qui contient les informations nécessaires pour que votre service vérifie si l'utilisateur a la permission dans l'organisation.
Les étapes détaillées de la demande d'un jeton d'organisation sont décrites dans Intégrer les organisations à votre application.
Supposons qu'Alice soit connectée à votre application et qu'elle veuille retirer un utilisateur dans l'Organisation A. Votre application peut demander un jeton d'organisation pour "Organisation A" avec la permission remove:member
(scope). Logto vérifiera si Alice a la permission dans l'organisation, et retournera un jeton d'organisation puisqu'elle a le rôle admin
:
Voici quelques exemples de cas d'erreur :
- Si Bob veut retirer un utilisateur dans l'Organisation A, Logto renverra une erreur puisqu'il n'a pas le rôle
admin
dans l'Organisation A. - Si Alice veut retirer un utilisateur dans l'Organisation B, Logto renverra également une erreur puisqu'elle n'a pas le rôle
admin
dans l'Organisation B. - Si Bob veut obtenir un jeton d'organisation avec n'importe quelle permission dans l'Organisation B, Logto renverra une erreur puisqu'il n'a pas l'adhésion dans l'Organisation B.
Après que votre application reçoit le jeton d'organisation, elle peut appeler votre service avec le jeton d'organisation en l'ajoutant à l'en-tête Authorization
.
Vérifier les jetons d'organisation dans votre service
Dans votre service, vous pouvez vérifier le jeton d'organisation par le processus standard de vérification JWT. Voir Vérifier les jetons d'organisation pour plus de détails.
Mettre à jour le modèle d'organisation
Lorsque vous devez mettre à jour le modèle d'organisation, par exemple, ajouter un nouveau rôle appelé developer
, vous pouvez le faire dans Logto Console ou via l'API de gestion de Logto. Le changement s'appliquera automatiquement à toutes les organisations sans aucun temps d'arrêt.
Conclusion
Avec Logto Organizations, la gestion et la scalabilité de la multi-location deviennent standardisées et confortables. Vous pouvez vous concentrer sur votre logique métier et laisser l'identité et le contrôle d'accès à Logto.