Passer au contenu principal
Il existe plusieurs cas d’utilisation où les utilisateurs appartiennent à des organizations tierces qui se sont inscrites aux services que vous fournissez. Ces utilisateurs peuvent être des employés d’une organization tierce, des clients, ou une combinaison des deux. Quelle que soit la situation, ce guide vous fournira un aperçu de haut niveau des cas d’utilisation courants pour les applications multilocataires. Les applications B2B s’efforcent de créer une expérience utilisateur agréable pour les employés et les clients des entreprises qu’elles servent. Pour cela, les fournisseurs de services dans les environnements B2B permettent souvent à chaque organization qui utilise leur service d’ajouter une certaine identité visuelle à celui-ci. Par exemple, supposons que vous travaillez pour AwesomeSaaS (une société de logiciels SaaS) et que votre entreprise utilise Human0, une application RH pour la gestion des avantages sociaux et d’autres fonctions RH. Vous accédez à votre application RH, et lorsque vous vous connectez, l’expérience de connexion est personnalisée pour afficher le logo d’AwesomeSaaS et utiliser les couleurs d’AwesomeSaaS. En tant que fournisseur de services B2B concevant une intégration avec Auth0, vous devrez envisager si vos clients (c’est-à-dire, les organizations tierces) autoriseront ou non les utilisateurs d’autres organizations à se connecter à leur instance de l’application, et si ces utilisateurs doivent être partagés entre les organizations ou isolés à une seule organization. Pour illustrer les différents cas d’utilisation. Travel0 est une entreprise fictive qui propose des services d’agence de voyage en ligne. Travel 0 possède plusieurs applications, mais, pour les besoins de ce travail, nous nous concentrerons sur deux d’entre elles, qui sont commercialisées directement auprès des entreprises.
  • Réservations corporatives Travel0 : fournit aux organizations une application en ligne où leurs employés peuvent se connecter et réserver des déplacements liés au travail. Les organizations clientes de cette aplication comprennent :
    • Hoekstra & Associates : un petit cabinet d’avocats avec seulement quelques employés. Ils ne disposent pas d’un service informatique et n’ont ni le temps ni les ressources pour apprendre à configurer un fournisseur d’identité d’entreprise (IdP).
    • Gupta & Smith Law : un cabinet d’avocats plus important, mais qui n’a également pas de service informatique et n’a ni le temps ni les ressources pour apprendre à configurer un fournisseur d’identité d’entreprise (IdP).
    • MetaHexa Bank : une grande organization financière. Ils fournissent des services bancaires et d’assurance et disposent de leur propre fournisseur d’identité (IdP).
    • Many Student University (MSU) : une grande université avec plusieurs campus, où chaque campus possède son propre fournisseur d’identité (IdP).
  • Travel0 Adventure Management : permet aux organizations de créer et de commercialiser des aventures telles que le rafting en eau vive. Les guides (qui sont des travailleurs indépendants ou des employés de certaines organizations de voyage ou d’événements tierces) peuvent utiliser cette application pour créer un compte et gérer les programmes pour diriger des aventures. Les organizations clientes de cette aplication comprennent :
    • AdventureZ : un grand organisateur de circuits/événements. Ils ont leur propre fournisseur d’identité (IdP) qu’ils utilisent pour leurs employés. Ils ont rarement besoin de pigistes car ils ont suffisamment de guides en interne, dont certains ne travaillent que pendant les périodes chargées. Ils permettent également à leurs guides de travailler en tant que pigistes pour d’autres entreprises.
    • Rocky Mountain High Adventures : un nouveau groupe faisant son entrée sur le marché pour la première fois. Les cofondateurs dirigent des visites. Ils font principalement appel à des pigistes pour obtenir de l’aide pendant les périodes chargées.
    • Suzie’s Rafting and Ziplines : cette entreprise existe depuis longtemps. Ils ont une équipe de guides gérant la plupart de leurs événements, mais ils emploient également des pigistes lorsqu’ils sont occupés.

​
Terminologie

Plusieurs des mots utilisés dans les instructions fournies peuvent avoir plusieurs significations différentes. Prenez un moment pour lire chaque définition afin de savoir clairement, en lisant les exemples, qui remplit quel rôle :
  • Locataire Auth0 (également appelé serveur d’autorisation): locataire que vous créez dans Auth0. Il s’agit d’une instance d’un serveur d’autorisation et représente un ou plusieurs domaines d’utilisateurs.
  • Organizations Auth0 : fait référence à la fonctionnalité de locataire Auth0 conçue pour soutenir les organizations. Une instance d’une organization Auth0 fera généralement référence à un de vos clients en particulier.
  • Employé : personne qui travaille pour votre entreprise. Ils auront généralement un compte dans votre fournisseur d’identité () et peuvent avoir besoin d’un accès administrateur à une ou plusieurs instances de locataire d’organization. Nous n’utiliserons le terme « employé » que pour faire référence aux employés de votre entreprise. Pour les utilisateurs qui appartiennent aux organizations de vos clients, consultez Utilisateur de l’organization.
  • Fournisseur d’identité (IdP) : service, comme Auth0, qui gère l’authentification des utilisateurs et, en option, fournit des informations de profil utilisateur et/ou la gestion des identifiants. Le service peut également fournir la délégation de la validation des identifiants et la gestion des profils via l’utilisation d’un fournisseur d’identité tiers (tel que Microsoft Entra ID, Google, Facebook, etc.).
  • Organization  :entreprise tierce qui est l’un de vos clients. Vous pouvez faire référence à une instance d’organization créée pour votre application comme un locataire. Nous l’appellerons un locataire d’organization pour éviter toute confusion avec un locataire Auth0.
  • Locataire d’organization : fait référence à un locataire qui peut être créé pour votre client dans le cadre de votre abonnement/fourniture d’application. Cela est différent d’un locataire Auth0.
  • Utilisateur de l’organization : personne qui se connecte à l’application en tant que membre d’une organization. Il peut s’agir d’un employé (de l’organization) ou d’un client. Tout utilisateur mentionné dans un contexte organisationnel peut être considéré comme un utilisateur de l’organization.

​
Isolation des utilisateurs

Il est important de déterminer le type d’application que vous fournissez en matière d’isolement des utilisateurs de l’organization. Il existe deux approches fondamentales concernant la manière et l’endroit où chacun de ces utilisateurs est stocké : Les utilisateurs isolés par organization et les utilisateurs partagés entre organizations.
Architecture Scenarios - Multitenancy - Diagram - Multiple organizations shared decision
Le diagramme de flux ci-dessus décrit le processus de prise de décision. Vous devez également déterminer si un accès de type administratif est requis pour une instance d’organization. Cela peut être pour un employé de votre organization qui agit en tant qu’administrateur pour une ou plusieurs organizations, ou pour un autre tiers fournissant des services de centre d’assistance ou services similaires. Les sections suivantes fournissent des détails pour chaque approche de l’isolement des utilisateurs de l’organization. Prêtez une attention particulière aux scénarios atypiques associés à chacun (c’est-à-dire lorsque les utilisateurs ont besoin d’accéder à plus d’une organization), car ces types de cas d’utilisation déterminent souvent quelle approche correspond le plus étroitement à vos exigences.

​
Utilisateurs isolés par organization

Chaque organization a son propre ensemble d’utilisateurs, et les utilisateurs ne peuvent pas et ne devraient pas pouvoir accéder à d’autres organizations. S’ils tentent de le faire, ils devraient être rejetés comme non autorisés. Si vous le désirez, vous pouvez contraindre vos utilisateurs à créer un compte distinct pour chaque organization à laquelle ils appartiennent. En tant que personne, ils seraient considérés comme au moins deux utilisateurs différents. Dans ce scénario, un utilisateur est directement lié à l’organzsation à laquelle il appartient ou à laquelle il a accès. Les utilisateurs ont deux options pour se connecter : A) ils créent des identifiants dans le stockage d’identité provisionné pour l’organization appropriée (c’est-à-dire la connexion de base de données Identifiant utilisateur/mot de passe dans votre locataire Auth0), ou B) ils se connectent en utilisant le fournisseur d’identité (IdP) de leur propre organization. Dans ce cas d’utilisation, il ne serait pas logique qu’un utilisateur fasse partie de plusieurs organizations, et la meilleure pratique consiste à créer une identité distincte pour chaque organization. Voici un exemple de ce à quoi pourrait ressembler la réservation d’entreprise Travel0, représenté sous forme de diagramme :
Architecture Scenarios - Multitenancy - Diagram - Isolated users
Sally est un utilisateur typique : elle est employée chez MetaHexa Bank et ne peut accéder qu’à l’instance de réservation d’entreprise de MetaHexa Bank sur Travel0. Pat, par contre, est une utilisatrice atypique. Pat est une adjointe (technicienne) juridique indépendante. Elle travaille donc à la fois pour Hoekstra & Associates et Gupta & Smith Law. Elle utilisera une identité d’utilisateur distincte pour chaque entreprise lorsqu’elle se connectera à la plateforme de réservation d’entreprise Travel0. Cette méthode présente plusieurs avantages, notamment la réduction des risques d’erreurs en obligeant Pat à créer deux personnalités distinctes, une pour chaque cabinet d’avocats. Lorsque Pat réserve un voyage, elle doit se connecter séparément à l’instance dédiée à l’organization afin d’effectuer la réservation. La situation de Pat est probablement un cas d’utilisation rare. Cependant, elle illustre ce qui doit être pris en compte lors de la détermination des exigences d’isolation des utilisateurs. Si vous souhaitez isoler les utilisateurs de l’organization à laquelle ils sont associés, cela nécessite la création d’identités d’utilisateurs distinctes. Dans ce cas, il y a une identité distincte pour Pat lorsqu’elle accède à l’instance de réservation d’entreprise de Hoekstra & Associates, et une autre pour accéder à l’instance de réservation d’entreprise de Gupta & Smith Law.

​
Cas d’utilisation lors de l’isolement par organization

Les applications qui isolent les utilisateurs par organization prennent généralement en charge trois cas d’utilisation différents. Pour les exemples de cette section, nous utiliserons les scénarios d’application de réservation d’entreprise Travel0 décrits dans notre introduction. Travel0 est le client Auth0.
  • Les organizations qui ne disposent pas de leur propre fournisseur d’identité (IdP) ou ne savent pas comment l’utiliser. Il s’agit généralement de petites organizations qui n’ont pas de service informatique disponible pour configurer l’authentification unique () avec le fournisseur d’identité (IdP) de l’organization, ou qui n’ont pas de fournisseur d’identité (IdP) adapté à la tâche. Dans notre exemple de réservation corporative Travel0, Hoekstra & Associates est une telle organization.
  • Les organizations qui préfèrent configurer leur propre IdP afin que leurs employés n’aient pas à créer un nouvel ensemble d’identifiants pour votre application. La plupart des organiszations appartiennent à cette catégorie. Dans notre exemple de réservation corporative Travel0, MetaHexa Bank est une telle organization.
  • Les organizations qui nécessitent plusieurs options d’authentification. Des exemples de ce type d’organization comprennent celles qui acquièrent fréquemment de nouvelles entreprises, des organizations comme les écoles qui permettent au personnel et aux parents de se connecter à la même application, et des organizations qui invitent des partenaires ou des clients à se connecter à leur instance d’application (c’est-à-dire les organizations interentreprises orienté client). Dans nos exemples, Many Student University (MSU) serait une telle organization.
Pour les deux premiers types d’organizations, la solution tend à être assez simple. Ces organizations sont considérées comme des organizations à IdP unique, et l’approche est presque toujours la même. Pour en savoir plus, consultez Organizations à fournisseurs d’identité unique. Les organizations qui ont plusieurs IdP tendent vers un niveau de complexité supérieur, mais il existe quelques approches qui peuvent réduire cette complexité. Pour en savoir plus, consultez Organizations à fournisseurs d’identités multiples.

​
Utilisateurs partagés entre les organizations

Un utilisateur peut être affilié à plusieurs organizations, et il serait pratique pour lui de ne pas avoir à posséder un identifiant/compte distinct lorsqu’il navigue d’une organization à l’autre. Les organizations peuvent toujours utiliser leur propre fournisseur d’identité dans de tels cas.
Architecture Scenarios - Multitenancy - Diagram - Shared users
Dans ce scénario, l’utilisateur n’est plus directement lié à l’organization à laquelle il appartient ou à laquelle il a accès. Les utilisateurs ont désormais deux options pour se connecter : A) ils créent leurs propres identifiants dans le stockage d’identité généralement fourni (c’est-à-dire dans une seule base de données « Identifiant utilisateur/mot de passe » dans votre locataire Auth0), au lieu d’un magasin d’identité spécifiquement alloué à l’organization dans votre locataire Auth0, ou B) ils se connectent en utilisant le fournisseur d’identité (IdP) de leur propre organization. Une fois qu’un utilisateur a établi son identité, il se voit accorder l’autorisation d’accéder à chacune des organizations auxquelles il devrait avoir accès. Cela peut se traduire par l’accès à une seule organization ou à plusieurs. Les utilisateurs doivent comprendre qu’ils peuvent utiliser les mêmes identifiants pour se connecter à l’instance de chaque organization. En utilisant la gestion des aventures de Travel0 comme exemple, le diagramme ci-dessus montre à quoi cela pourrait ressembler. Jonno est un utilisateur typique. Jonno est un employé de Suzie’s Rafting and Ziplines. Jonno peut uniquement se connecter à l’instance de gestion des aventures de Travel0 fournie pour créer et guider des aventures pour Suzie’s Rafting and Ziplines. Les identifiants de Jonno sont stockés soit dans une connexion de base de données associée avec le locataire Auth0 Voyage0, soit dans l’IdP de Suzie’s Rafting and Ziplines (selon qu’ils souhaitent ou non gérer leurs identités utilisateur). Sumana est une utilisatrice atypique. Elle est employée par AdventureZ, mais, puisque cette entreprise coordonne aussi les possibilités de travail à la pige pour les petites sociétés de guides durant la haute saison, Sumana a été invitée à travailler comme pigiste pour Rocky Mountain High Adventures. Elle peut ainsi accéder aux instances d’AdventureZ et de Rocky Mountain de Travel0 Adventure Management. Cependant, comme elle n’a jamais été invitée comme guide chez Suzie’s Rafting and Ziplines, elle n’est pas autorisée à accéder à cette instance. Sumana doit avoir la même identité pour les deux organizations parce que le service de guide implique l’utilisation d’un système d’évaluation et que les évaluations de Sumana doivent être transférées et combinées entre les organizations avec lesquelles elle travaille. Les identifiants de Sumana, comme ceux de Jonno, sont stockés soit dans une connexion de base de données employée par le locataire Auth0 de Travel0, soit dans l’IdP d’AdventureZ (selon qu’AdventureZ souhaite ou non gérer les identités des utilisateurs). L’endroit où ses identifiants sont stockés n’a aucune incidence sur les instances de l’organization auxquelles elle a accès.

​
Accès administratif aux organizations

Dans certains scénarios, vous aurez besoin de fournir un accès administratif à l’ensemble de vos organizations. En règle générale, il s’agira de tâches administratives en dehors de la gestion du profil/compte utilisateur (comme décrit dans Gestion de profil), et vous devrez peut-être fournir un accès à vos employés ainsi qu’à des tiers.
Meilleure pratiqueActivez toujours l’authentification multifacteur (MFA) pour les administrateurs des locataires Auth0 qui ont un accès via le Auth0 Dashboard (Tableau de bord Auth0). Notez que vous devrez suivre un processus différent pour activer la MFA pour un administrateur de locataire Auth0 que pour activer la MFA pour le locataire Auth0 lui-même. Pour savoir comment activer la MFA pour un administrateur de locataire Auth0, consultez Gérer l’accès au tableau de bord avec authentification multifacteur (MFA).
Auth0 Dashboard peut être configuré à l’aide d’un contrôle d’accès basé sur les rôles (RBAC), ce qui vous permettra de définir des rôles particuliers pour vos employés dans l’ensemble de votre déploiement de locataire Auth0. Vous pouvez même tirer parti de votre propre IdP d’entreprise pour fournir une authentification d’administrateur de locataire Auth0 à vos employés, ainsi qu’un accès étendu d’administrateur de locataire à des tiers de confiance. Pour d’autres accès administratifs, vous voudrez généralement construire votre propre API et/ou application que vous utiliserez en collaboration avec l’Auth0 . Il n’est pas conseillé de fournir un accès administratif à votre locataire Auth0 via Auth0 Dashboard pour une large gamme d’utilisateurs. Bien que la création d’une telle application/API dépasse le cadre de ce document, il est conseillé de demander de l’aide aux Services professionnels Auth0 avant de commencer un tel projet.

​
En savoir plus