Architecture à organisations multiples

Un guide d’intégration sur les architectures multilocataires qui doivent prendre en charge des instances d’application pour plusieurs organisations Auth0.

Il existe plusieurs cas d’utilisation où les utilisateurs appartiennent à des organisations tierces qui se sont inscrites aux services que vous fournissez. Ces utilisateurs peuvent être des employés d’une organisation tierce, des clients ou les deux. Quelle que soit la situation, ce guide vous donnera un aperçu général des cas d’utilisation courants des applications multilocataires.

Les applications B2B visent à offrir une expérience utilisateur agréable aux employés et aux clients des entreprises qu’elles servent. Pour y parvenir, les fournisseurs de services dans les environnements B2B permettent souvent d’ajouter une image de marque distincte à leur service pour chacune des organisations qui l’utilisent. Par exemple, supposons que vous travaillez pour AwesomeSaaS (une entreprise de logiciels SaaS) et que votre entreprise utilise Human0, une application de RH pour gérer les avantages sociaux et d’autres fonctions RH. Vous accédez à votre application de RH et, lorsque vous ouvrez une session, l’expérience de connexion est personnalisée pour afficher le logo et les couleurs d’AwesomeSaaS.

En tant que fournisseur de services B2B qui conçoit une intégration avec Auth0, vous devrez déterminer si vos clients (c.-à-d. des organisations tierces) permettront ou non à des utilisateurs d’autres organisations d’ouvrir une session dans leur instance de l’application, et si ces utilisateurs doivent être partagés entre les organisations ou isolés au sein d’une seule organisation.

Commençons par présenter quelques exemples d’applications qui mettront en lumière les différents cas d’utilisation. Travel0 est une entreprise fictive qui offre des services d’agence de voyages en ligne. Travel0 a plusieurs applications, mais dans le cadre de cet exercice, nous nous concentrerons sur deux applications commercialisées directement auprès des organisations :

• Travel0 Corporate Booking : offre aux organisations une application en ligne dans laquelle leurs employés peuvent ouvrir une session et réserver des déplacements professionnels. Les organisations clientes de cette application comprennent :

  • Hoekstra & Associates : un petit cabinet d’avocats comptant seulement quelques employés. Il n’a pas de service informatique et n’a ni le temps ni les ressources nécessaires pour apprendre à configurer un fournisseur d’identité (IdP) d’entreprise.
  • Gupta & Smith Law : un cabinet d’avocats plus important, mais lui non plus n’a pas de service informatique et n’a ni le temps ni les ressources nécessaires pour apprendre à configurer un IdP d’entreprise.
  • MetaHexa Bank : une grande organisation du secteur financier. Elle fournit des services bancaires et d’assurance et possède son propre IdP.
  • Many Student University (MSU) : une grande université comptant plusieurs campus, où chaque campus a son propre IdP.

• Travel0 Adventure Management : permet aux organisations de créer et de commercialiser des aventures comme le rafting en eau vive. Les guides (qui sont pigistes ou employés d’une organisation tierce du secteur du voyage ou de l’événementiel) peuvent utiliser cette application pour créer un compte et gérer leur horaire afin d’encadrer des aventures. Les organisations clientes de cette application comprennent :

  • AdventureZ : un grand organisateur de circuits et d’événements. Il a son propre IdP, qu’il utilise pour ses employés. Il a rarement besoin de pigistes, car il compte suffisamment de guides parmi son personnel, dont certains ne travaillent que pendant les périodes achalandées. Il permet aussi à ses guides de faire du travail autonome pour d’autres entreprises.
  • Rocky Mountain High Adventures : un nouveau groupe qui entre sur le marché pour la première fois. Les cofondateurs organisent eux-mêmes les circuits; ils font appel à des pigistes pendant les périodes achalandées.
  • Suzie’s Rafting and Ziplines : cette entreprise existe depuis longtemps. Elle dispose d’une équipe de guides qui prennent en charge la plupart de ses événements, mais elle embauche aussi des pigistes lorsqu’elle est très occupée.

​

Terminologie

Plusieurs des termes utilisés dans les directives ci-dessous peuvent avoir des sens différents. Prenez un moment pour lire chaque définition afin de bien comprendre, en parcourant les exemples, qui assume 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 qui représente un ou plusieurs domaines d’utilisateurs.
• Auth0 Organizations: Désigne la fonctionnalité locataire Auth0 conçue pour prendre en charge les organisations. Une instance d’une Auth0 Organization renvoie généralement à l’un de vos clients en particulier.
• Employé : Personne qui travaille pour votre entreprise. Elle aura généralement un compte dans votre fournisseur d’identité (IdP) et peut avoir besoin d’un accès administrateur à une ou plusieurs instances de locataire d’organisation. Nous utiliserons le terme Employé uniquement pour désigner les employés de votre entreprise. Pour les utilisateurs qui appartiennent aux organisations de vos clients, consultez Utilisateur d’organisation.
• Fournisseur d’identité (IdP) : Service, comme Auth0, qui gère l’authentification des utilisateurs et qui peut aussi fournir des renseignements de profil utilisateur et/ou la gestion des identifiants. Le service peut également déléguer la validation des identifiants et la gestion du profil à un IdP tiers (comme Azure AD, Google, Facebook, etc.)
• Organisation: Entreprise tierce qui est l’un de vos clients. Vous pouvez appeler locataire une instance d’organisation créée pour votre application; nous l’appellerons un locataire d’organisation afin d’éviter toute confusion avec un locataire Auth0.
• Locataire d’organisation: Désigne un locataire créé pour votre client dans le cadre de l’abonnement ou du provisionnement de votre application. Il est distinct d’un locataire Auth0.
• Utilisateur d’organisation : Personne qui se connecte à l’application en tant que membre d’une organisation. Il peut s’agir d’un employé (de l’organisation) ou d’un client. Tout utilisateur mentionné dans un contexte d’organisation peut être considéré comme un utilisateur d’organisation.

​

Isolation des utilisateurs

Il est important de déterminer le type d’application que vous proposez en matière d’isolation des utilisateurs par organisation. Il existe deux approches fondamentales quant à la façon et à l’endroit où ces utilisateurs sont stockés : les utilisateurs isolés par organisation et les utilisateurs partagés entre les organisations.

Le diagramme de flux ci-dessus présente le processus décisionnel. Vous devez également déterminer si un accès de type administratif est requis pour une instance d’organisation. Il peut s’agir d’un employé de votre organisation qui agit à titre d’administrateur pour une ou plusieurs organisations, ou d’un autre tiers qui fournit des services de centre d’assistance ou des services semblables.

Les sections suivantes fournissent des précisions sur chaque approche d’isolation des utilisateurs par organisation. Portez une attention particulière aux scénarios atypiques associés à chacune d’elles (c.-à-d. lorsque des utilisateurs doivent accéder à plus d’une organisation), car ce type de cas d’utilisation détermine souvent quelle approche correspond le mieux à vos besoins.

​

Utilisateurs isolés par organisation

Chaque organisation a son propre ensemble d’utilisateurs, et les utilisateurs ne peuvent pas et ne devraient pas pouvoir accéder à d’autres organisations. S’ils tentent de le faire, l’accès doit leur être refusé parce qu’ils ne sont pas autorisés. Si vous le souhaitez, vous pouvez obliger vos utilisateurs à créer un compte distinct pour chaque organisation à laquelle ils appartiennent. Une même personne serait alors considérée comme deux utilisateurs distincts ou plus.

Dans ce scénario, un utilisateur est directement rattaché à l’organisation à laquelle il appartient ou à laquelle il a accès. Les utilisateurs ont deux options pour se connecter : A) ils créent des identifiants dans un stockage d’identités provisionné pour l’organisation appropriée (c.-à-d. une connexion de base de données UserID/Password dans votre locataire Auth0), ou B) ils se connectent au moyen de l’IdP de leur propre organisation. Dans ce cas d’utilisation, il n’aurait pas de sens qu’un utilisateur fasse partie de plusieurs organisations, et la meilleure pratique consisterait à créer une identité distincte pour chaque organisation. En prenant Travel0 Corporate Booking comme exemple, le diagramme ci-dessous montre à quoi cela ressemblerait :

Sally est une utilisatrice typique : elle est employée de MetaHexa Bank et ne peut accéder qu’à l’instance Travel0 Corporate Booking de MetaHexa Bank.

Pat, en revanche, est une utilisatrice atypique. Pat est parajuriste pigiste; elle travaille donc à la fois pour Hoekstra & Associates et Gupta & Smith Law, et accédera à l’instance Travel0 Corporate Booking de chacune au moyen d’une identité utilisateur distincte. L’un des grands avantages de cette approche est de réduire le risque d’erreur en obligeant Pat à créer deux identités distinctes — une pour chaque cabinet d’avocats. Lorsque Pat réserve un voyage, elle doit se connecter séparément à l’instance précise de l’organisation pour effectuer la réservation.

La situation de Pat est probablement un cas d’utilisation rare. Toutefois, elle illustre les éléments à prendre en compte pour définir les exigences d’isolation des utilisateurs. Si vous voulez isoler les utilisateurs au sein de l’organisation à laquelle ils sont associés, cela exige la création d’identités utilisateur distinctes. Dans ce cas, Pat a une identité lorsqu’elle accède à l’instance Travel0 Corporate Booking de Hoekstra & Associates, et une autre lorsqu’elle accède à l’instance Travel0 Corporate Booking de Gupta & Smith Law.

​

Cas d’utilisation de l’isolation par organisation

Les applications dont les utilisateurs sont isolés par organisation prennent généralement en charge trois cas d’utilisation distincts. Pour les exemples de cette section, nous utiliserons les scénarios de l’application Travel0 Corporate Booking décrits dans notre introduction. Travel0 est le client d’Auth0.

• Les organisations qui n’ont pas leur propre IdP ou qui ne savent pas comment l’utiliser. Il s’agit généralement de petites organisations qui ne disposent pas d’un service TI pour configurer l’authentification unique (SSO) avec le fournisseur d’identité (IdP) de l’organisation, ou qui n’ont pas de fournisseur d’identité organisationnel adapté à cette fin. Dans notre exemple Travel0 Corporate Booking, Hoekstra & Associates est une telle organisation.
• Les organisations qui préfèrent configurer leur propre IdP afin que leurs employés n’aient pas à créer de nouveaux identifiants pour votre application. La plupart des organisations entrent dans cette catégorie. Dans notre exemple Travel0 Corporate Booking, MetaHexa Bank est une telle organisation.
• Les organisations qui exigent plusieurs options d’authentification. Parmi les exemples de ce type d’organisation, on trouve celles qui acquièrent fréquemment de nouvelles entreprises, les organisations comme les écoles qui permettent au personnel et aux parents de se connecter à la même application, ainsi que les organisations qui invitent des partenaires ou des clients à se connecter à leur instance d’application (c.-à-d. des organisations B2B2C). Dans nos exemples, Many Student University (MSU) serait une telle organisation.

Pour les deux premiers types d’organisations, la solution est généralement assez simple. Ces organisations sont considérées comme des organisations à IdP unique, et l’approche est presque toujours la même. Pour en savoir plus, consultez Organisations avec un fournisseur d’identité unique.

Les organisations qui ont plus d’un IdP présentent généralement un degré de complexité plus élevé, mais quelques approches permettent de la réduire. Pour en savoir plus, consultez Organisations avec plusieurs fournisseurs d’identité.

​

Utilisateurs partagés entre des organisations

Un utilisateur peut appartenir à plus d’une organisation, et il est pratique qu’il n’ait pas besoin d’avoir une identité ou un compte distinct lorsqu’il passe d’une organisation à l’autre. Dans de tels cas, les organisations peuvent tout de même utiliser leur propre IdP.

Dans ce scénario, un utilisateur n’est plus directement lié à l’organisation à laquelle il appartient ou à laquelle il a accès. Les utilisateurs disposent maintenant de deux options pour se connecter : A) créer des identifiants dans un référentiel d’identités provisionné de façon générale (c.-à-d. dans une seule connexion de base de données UserID/Password de votre locataire Auth0), plutôt que dans un référentiel d’identités attribué spécifiquement à l’organisation dans votre locataire Auth0, ou B) se connecter au moyen de l’IdP de leur propre organisation. Une fois qu’un utilisateur possède une identité, il reçoit l’autorisation d’accéder à chacune des organisations auxquelles il doit avoir accès. Cela peut signifier l’accès à une seule organisation ou à plusieurs. Les utilisateurs doivent comprendre que, lorsqu’on leur demande de se connecter, ils peuvent utiliser les mêmes identifiants pour accéder à l’instance de chaque organisation. En prenant Travel0 Adventure Management comme exemple, le diagramme ci-dessus montre à quoi cela ressemble.

Jonno est un utilisateur typique. Jonno est un employé de Suzie’s Rafting and Ziplines. Jonno peut seulement se connecter à l’instance de Travel0 Adventure Management provisionnée 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 au locataire Auth0 de Travel0, soit dans l’IdP de Suzie’s Zipline and Rafting (selon qu’ils souhaitent gérer ou non les identités des utilisateurs).

Sumana est une utilisatrice atypique. Sumana est une employée d’AdventureZ, mais comme AdventureZ coordonne aussi des occasions de travail autonome pour les plus petites entreprises de guides pendant les périodes de pointe, Sumana a été invitée à se joindre à Rocky Mountain High Adventures comme pigiste. Sumana est autorisée à se connecter aux instances de Travel0 Adventure Management d’AdventureZ et de Rocky Mountain. Toutefois, comme elle n’a jamais été invitée à agir comme guide pour 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 organisations, parce que l’activité de guide repose sur l’utilisation d’un système d’évaluation et que ses évaluations doivent être reportées et combinées entre les organisations avec lesquelles elle travaille. Les identifiants de Sumana, comme ceux de Jonno, sont stockés soit dans une connexion de base de données associée au locataire Auth0 de Travel0, soit dans l’IdP d’AdventureZ (selon qu’AdventureZ souhaite gérer ou non les identités des utilisateurs). L’endroit où ses identifiants sont stockés n’a aucune incidence sur les instances d’organisation auxquelles elle a accès.

​

Accès administratif aux organisations

Dans certains cas, vous devrez fournir un accès administratif à l’ensemble de vos organisations. En général, il s’agira de tâches administratives qui ne relèvent pas de la gestion du profil/compte utilisateur (comme décrit dans Gestion du profil), et vous pourriez devoir accorder cet accès à vos employés ainsi qu’à des tiers.

Bonne pratique

Activez toujours l’authentification multifacteur (MFA) pour les administrateurs du locataire Auth0 qui ont accès à l’Auth0 Dashboard. Notez que le processus pour activer la MFA pour un administrateur du locataire Auth0 est différent de celui utilisé pour activer la MFA pour le locataire Auth0 lui-même. Pour savoir comment activer la MFA pour un administrateur du locataire Auth0, consultez Gérer l’accès au Dashboard avec l’authentification multifacteur.

L’Auth0 Dashboard peut être configuré au moyen du contrôle d’accès basé sur les rôles, ce qui vous permettra de définir des rôles précis pour vos employés à l’échelle de l’ensemble de votre déploiement de locataires Auth0. Vous pouvez même utiliser votre propre IdP d’entreprise pour authentifier vos employés comme administrateurs du locataire Auth0, ainsi que pour accorder un accès étendu d’administrateur du locataire à des tiers de confiance.

Pour tout autre accès administratif, vous voudrez généralement créer votre propre API ou application, que vous utiliserez conjointement avec la Management API d’Auth0. Il n’est pas recommandé d’accorder un accès administratif à votre locataire Auth0 via l’Auth0 Dashboard à un grand nombre d’utilisateurs. Bien que la création d’une telle application/API dépasse la portée de ce document, il est recommandé de demander l’aide des Services professionnels Auth0 avant de vous lancer dans une telle démarche.

​

En savoir plus

• organisation avec fournisseur d’identité unique
• Organisations avec plusieurs fournisseurs d’identité