Avez-vous vraiment besoin de plusieurs locataires pour gérer votre système d'identité ?
Le concept de « locataire » est relativement méconnu de la plupart des utilisateurs, mais il est particulièrement important pour construire des modèles d'identité. Dans cet article, nous passerons en revue des exemples pour aider tout le monde à comprendre quel type de modèle d'identité convient à leur entreprise.
Darcy YeDeveloper
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.
Avec la maturité croissante des outils low-code et des services cloud aujourd'hui, accompagnée de l'accélération de la symbiose des outils d'IA, le seuil de développement des applications est grandement abaissé et de plus en plus d'applications apparaissent sur le marché.
Qu'elles soient complexes ou simples, la plupart des applications impliquent des scénarios d'inscription et de connexion des utilisateurs, permettant ainsi aux utilisateurs d'obtenir des services plus stables, sécurisés et personnalisés. Et pour résoudre le problème de connexion et d'inscription des utilisateurs, la première étape est de construire un système d'identité.
Pour de nombreuses applications grand public, leurs modèles d'identité sont souvent relativement simples, voire se limitent à un e-mail et un mot de passe. Pour les applications en phase de croissance rapide et attirant de nouveaux utilisateurs, cela suffit ; mais une fois que l'application a son propre modèle commercial, même dans le cas le plus simple, par exemple, la diffusion de publicités, il est nécessaire de faire la distinction entre les comptes utilisateurs ordinaires et les comptes annonceurs. Les comptes annonceurs peuvent personnaliser les échelles de diffusion, le contenu, etc.; tandis que les utilisateurs ordinaires ne peuvent que consulter du contenu gratuit et des publicités, etc.
Logto est une solution d'identité basée sur le cloud, et il existe également une solution logicielle open source (OSS) avec le même noyau que les services cloud pour les utilisateurs ayant des besoins spécifiques pour effectuer des personnalisations. Le service de Logto est construit sur un système multi-locataires, où chaque utilisateur de Logto crée son propre compte et peut gérer plusieurs locataires au sein du compte. D'autres services d'identité cloud ont également des architectures similaires, chaque service cloud ayant sa propre définition de "locataire", donc le modèle de locataire que nous discutons dans cet article est limité au scénario de Logto, et pour d'autres fournisseurs, il peut y avoir d'autres concepts correspondants.
Notamment, dans le modèle multi-locataires de Logto, les données entre locataires (toutes les informations des utilisateurs finaux) sont isolées, de sorte que les utilisateurs de Logto peuvent gérer les données de comptes d'utilisateurs finaux selon leurs besoins métier au sein d'un seul compte Logto. De nombreux autres services d'identité cloud ne peuvent prendre en charge qu'un locataire par compte, ce qui oblige les utilisateurs qui doivent gérer plusieurs locataires simultanément à changer fréquemment de compte, ce qui entraîne une mauvaise expérience.
Après tout cela, comment devez-vous choisir un modèle de compte adapté à votre application ? Ici, nous examinons trois cas.
Cas 1 : application fournissant directement un service aux utilisateurs finaux#
Le modèle d'identité dans ce type d'applications est assez simple. Utilisons une application de streaming musical par exemple — à part l'administrateur (l’utilisateur "foo" de Logto, qui est le propriétaire du locataire dans ce cas, a intrinsèquement accès à l'administration), il n'y a que des utilisateurs finaux.
Dans ce scénario, les utilisateurs finaux peuvent être divisés en trois types :
Utilisateur plan gratuit : Ne peut jouer que de la musique gratuite
Utilisateur plan payant : Peut jouer de la musique gratuite et créer ses propres playlists
Utilisateur premium : En plus de jouer de la musique gratuite et de créer des playlists, peut également jouer des musiques HiFi
Dans ce scénario d'application, nous n'avons besoin que de trois types de rôles (gratuit, payant, premium), chacun avec des autorisations différentes. Donc, après la connexion de l'utilisateur final, Logto peut décider si un service spécifique (par exemple, accès aux musiques HiFi) lui sera fourni en fonction du rôle qu'il détient. À ce stade, nous n'avons besoin que d'un seul locataire pour répondre aux exigences.
Une plateforme qui connecte des prestataires de services tiers et des utilisateurs finaux, ce qui est également un modèle commercial 2C très courant de nos jours. Il y a deux groupes d'utilisateurs à prendre en compte - en utilisant une application de e-commerce comme exemple, ce sont les marchands (prestataires de services) et les acheteurs (utilisateurs finaux).
Il y a deux manières de construire le modèle d'identité ici :
Mettre les groupes d'utilisateurs d'acheteurs et de marchands sous le même locataire.
Mettre les acheteurs et les marchands dans deux locataires différents respectivement.
Pour rendre l'exemple plus compréhensible, nous supposons que les acheteurs peuvent passer des commandes ou consulter les descriptions de produits ; les marchands peuvent changer les prix des produits, modifier les descriptions de produits et consulter l'inventaire des produits. Les marchands consultent les descriptions de produits pour les aider à identifier les problèmes et mettre à jour les informations des produits en temps voulu.
Pour le modèle d'identité 1, il n'y a qu'une seule application. Tous les utilisateurs qui s'enregistrent deviennent des acheteurs. Si quelqu'un doit vendre des choses, il peut ajouter ses propres produits à vendre, de sorte que ces utilisateurs finaux obtiendront des autorisations de marchand en plus des autorisations d'acheteur pour gérer leurs propres produits.
Pour le modèle d'identité 2, chaque locataire a ses propres informations d'identité uniques et sa propre passerelle d'autorisation séparée, chaque locataire doit donc avoir sa propre application distincte. Dans le cas d'exemple, il y aurait une application acheteur et une application marchand. Les comptes acheteur ne peuvent pas devenir marchands, et les comptes marchands ne peuvent pas non plus devenir acheteurs. Si les marchands veulent consulter les descriptions de leurs propres produits sous l'angle de l'acheteur comme dans le modèle 1, ils doivent réimplémenter la même fonctionnalité dans l'application marchand, ou s'inscrire à un compte d'application acheteur pour le consulter. Cela ajoute beaucoup de complexité, mais l'avantage est que les identités d'acheteur et de marchand sont complètement isolées.
Si les marchands ont de nombreux produits différents à gérer, l'utilisation du modèle d'identité 2 et le développement d'une application marchande plus spécialisée devraient être un meilleur choix. Le modèle 1 est plus adapté aux plateformes comme eBay, où les marchands n'ont pas beaucoup de produits et n'ont pas besoin de fonctionnalités de gestion de produits trop complexes.
Cas 3 : Applications développées par une entreprise de conseil en informatique#
Supposons qu'il y ait une entreprise de conseil technique en informatique dont les clients n'ont pas la capacité de développer eux-mêmes des systèmes informatiques, ils doivent donc rechercher des services techniques auprès de cette entreprise.
En supposant que l'entreprise ait deux clients, l'un étant un système de gestion de livres interne pour une librairie, et l'autre un système de réservation pour un hôtel.
Du point de vue du propriétaire de la librairie, je ne souhaite évidemment pas que les clients de l'hôtel puissent se connecter aléatoirement à mon système de gestion de livres, car cela serait très peu sûr. Par conséquent, du point de vue de la protection de la vie privée, un locataire distinct doit être créé pour chaque client, en utilisant le mécanisme d'isolation des informations des locataires, pour garantir que les données des clients ne sont pas visibles par d'autres clients.
Comme nous l'avons mentionné auparavant, même si vous avez besoin de créer plusieurs locataires, Logto peut vous aider à gérer plusieurs locataires au sein d'un seul compte, ce qui est plus pratique et sécurisé par rapport à certains autres services qui vous obligent à créer et à gérer plusieurs comptes vous-même.
Grâce aux exemples présentés ci-dessus, vous devez avoir compris quand vous avez besoin de créer plusieurs locataires, dans quels scénarios vous pouvez avoir un seul locataire ou plusieurs locataires, et selon vos propres besoins commerciaux, choisissez la solution de modèle d'identité qui vous convient le mieux.
L'équipe Logto vise à s'assurer que la question de "savoir si plusieurs locataires doivent être créés" ne constitue pas un obstacle pour toute entreprise. Si vous n'êtes pas certain que votre scénario d'entreprise peut être réalisé avec un seul locataire, veuillez rejoindre la communauté Logto pour consultation. Votre question peut également être celle de quelqu'un d'autre, alors partagez les défis auxquels vous êtes confronté avec nous pour aider à améliorer l'évolutivité des produits Logto.
Si vous sélectionnez un cadre d'identité pour votre application, Logto vaut la peine d'être essayé. Il fournit une solution clé en main adaptée à divers scénarios d'entreprise, des petites entreprises aux applications à grande échelle !
