Architecture à organisations multiples

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

Il existe plusieurs cas d’utilisation dans lesquels les utilisateurs appartiennent à des organisations tierces qui se sont inscrites aux services que vous offrez. Ces utilisateurs peuvent être des employés d’une organisation tierce, des clients ou une combinaison des 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 l’image de marque de chaque organisation qui utilise leur service. Par exemple, disons que vous travaillez pour AwesomeSaaS (une entreprise de logiciels SaaS) et que votre entreprise utilise Human0, une application RH servant à gérer les 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 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 aux utilisateurs d’autres organisations de se connecter à leur instance de l’application, et si ces utilisateurs doivent être partagés entre plusieurs organisations ou isolés dans une seule organisation.

Commençons par présenter quelques exemples d’applications qui mettront en évidence 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, pour les besoins de cet exercice, nous nous concentrerons sur deux applications commercialisées directement auprès des organisations :

• Travel0 Corporate Booking : Fournit aux organisations une application en ligne dans laquelle leurs employés peuvent se connecter 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 département TI et n’a ni le temps ni la capacité d’apprendre à configurer un fournisseur d’identité (IdP) d’entreprise.
  • Gupta & Smith Law : Un cabinet d’avocats plus grand, mais qui n’a pas non plus de département TI et n’a ni le temps ni la capacité d’apprendre à configurer un IdP d’entreprise.
  • MetaHexa Bank : Une grande organisation du secteur financier. Elle offre 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 possède son propre IdP.

• Travel0 Adventure Management : Permet aux organisations de créer et de promouvoir des aventures comme des descentes de rafting en eau vive. Les guides (qui sont des pigistes ou des 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 l’horaire des aventures qu’ils encadrent. 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 parce qu’il compte suffisamment de guides à l’interne, 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 fait son entrée sur le marché. Les cofondateurs organisent eux-mêmes des excursions; ils font appel à des pigistes pour obtenir de l’aide pendant les périodes achalandées.
  • Suzie’s Rafting and Ziplines : Cette entreprise existe depuis longtemps. Elle dispose d’une équipe de guides qui s’occupe de la plupart de ses événements, mais elle embauche aussi des pigistes pendant les périodes achalandées.

​

Terminologie

Plusieurs des termes utilisés dans les lignes directrices ci-dessous peuvent avoir des sens différents. Prenez un moment pour lire chaque définition afin de bien comprendre, dans les exemples, qui remplit quel rôle :

• Auth0 Tenant (aussi appelé Serveur d’autorisation): tenant 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é d’Auth0 Tenant conçue pour prendre en charge les Organizations. Une instance d’une Auth0 Organization renverra généralement à l’un de vos clients en particulier.
• Employee: Personne qui travaille pour votre entreprise. Elle aura généralement un compte dans votre fournisseur d’identité (IdP) et pourrait avoir besoin d’un accès administrateur à une ou plusieurs instances d’Organization Tenant. Nous n’utiliserons le terme Employee que pour désigner les employés de votre entreprise. Pour les utilisateurs qui appartiennent aux Organizations de vos clients, consultez Organization User.
• Identity Provider (IdP): Service, comme Auth0, qui gère l’authentification des utilisateurs et qui, au besoin, fournit des renseignement du profil utilisateur ou la gestion des informations d’authentification. Le service peut aussi assurer la délégation de la validation des informations d’authentification et la gestion du profil au moyen d’un IdP tiers (comme Azure AD, Google, Facebook, etc.)
• Organization: Entreprise tierce qui est l’un de vos clients. Vous pouvez désigner comme tenant une instance d’organization créée pour votre application; nous l’appellerons Organization Tenant afin d’éviter toute confusion avec un Auth0 Tenant.
• Organization Tenant: Désigne un tenant créé pour votre client dans le cadre de l’abonnement ou du provisionnement de votre application. Cela est différent d’un Auth0 Tenant.
• Organization User: 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 organization context peut être considéré comme un Organization User.

​

Isolement des utilisateurs

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

Le diagramme ci-dessus présente le processus décisionnel. Vous devriez aussi déterminer si un accès de type administratif est requis pour une organisation donnée. Cela peut être le cas d’un employé de votre organisation qui agit à titre d’administrateur pour une ou plusieurs organisations, ou encore d’un tiers qui fournit des services de centre d’assistance ou des services semblables.

Les sections suivantes présentent en détail chacune des approches d’isolement des utilisateurs par organisation. Portez une attention particulière aux scénarios atypiques associés à chacune (c.-à-d. lorsque des utilisateurs doivent avoir accès à 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 Organization

Chaque organisation possède son propre ensemble d’utilisateurs, et les utilisateurs ne peuvent pas et ne devraient pas pouvoir accéder à d’autres organisations. S’ils essaient de le faire, leur accès doit être refusé comme non autorisé. Au besoin, vous pouvez forcer vos utilisateurs à créer un compte distinct pour chaque organisation à laquelle ils appartiennent. Autrement dit, une même personne serait considérée comme deux utilisateurs différents 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 façons de se connecter : A) ils créent des identifiants dans le stockage d’identités provisionné pour l’organisation appropriée (c.-à-d. une UserID/Password Database Connection dans votre tenant Auth0), ou B) ils se connectent au moyen de l’IdP de leur propre organisation. Dans ce cas d’utilisation, il ne serait pas logique qu’un utilisateur fasse partie de plusieurs organisations; la meilleure pratique consisterait plutôt à 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 elle ne peut accéder qu’à l’instance de 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 elle accédera à l’instance de Travel0 Corporate Booking de chacune au moyen d’une identité utilisateur distincte. L’un des nombreux avantages de cette approche est de réduire le risque d’erreurs en obligeant Pat à créer deux personas distincts—un pour chaque cabinet d’avocats. Lorsqu’elle réserve un voyage, Pat doit se connecter séparément à l’instance de l’organisation concernée pour effectuer la réservation.

La situation de Pat est probablement un cas d’utilisation rare. Elle illustre toutefois les éléments à prendre en compte pour déterminer les exigences en matière d’isolation des utilisateurs. Si vous souhaitez isoler les utilisateurs selon l’organisation à laquelle ils sont associés, il faut créer des identités utilisateur distinctes. Dans ce cas, Pat a une identité lorsqu’elle accède à l’instance de Travel0 Corporate Booking de Hoekstra & Associates, et une autre lorsqu’elle accède à l’instance de Travel0 Corporate Booking de Gupta & Smith Law.

​

Cas d’utilisation lors de l’isolation par organisation

Les applications où 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.

• 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 n’ont pas de département 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é adapté à ce besoin. Dans notre exemple de Travel0 Corporate Booking, Hoekstra & Associates est une organisation de ce type.
• Organisations 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 organisations entrent dans cette catégorie. Dans notre exemple de Travel0 Corporate Booking, MetaHexa Bank est une organisation de ce type.
• 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 celles 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 organisation de ce type.

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 Single Identity Provider Organizations.

Les organisations qui ont plus d’un IdP tendent à être plus complexes, mais certaines approches permettent d’en réduire la complexité. Pour en savoir plus, consultez Multiple Identity Provider Organizations.

​

Utilisateurs partagés entre les Organizations

Un utilisateur peut appartenir à plus d’une organisation, et il serait pratique qu’il n’ait pas besoin d’une identité ou d’un compte distinct lorsqu’il passe d’une organisation à l’autre. Dans de tels cas, les Organizations 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 ont maintenant deux options pour se connecter : A) ils créent des informations d’identification dans un stockage d’identités provisionné de façon générale (c.-à-d. dans une seule Database Connection UserID/Password de votre tenant Auth0), plutôt que dans un identity store attribué spécifiquement dans votre tenant Auth0 pour l’organisation, ou B) ils se connectent au moyen de l’IdP de leur propre organisation. Une fois qu’un utilisateur a une identité, il reçoit ensuite l’autorisation d’accéder à chacune des organisations auxquelles il devrait avoir accès. Cela peut signifier un accès à une seule organisation, ou encore à plus d’une organisation. Les utilisateurs devront comprendre que, lorsqu’on leur demande de se connecter, ils peuvent utiliser les mêmes informations d’identification pour accéder à l’instance de chaque organisation. En prenant Travel0 Adventure Management comme exemple, le diagramme ci-dessus montre à quoi cela ressemblerait.

Jonno est un utilisateur typique. Jonno est un employé de Suzie’s Rafting and Ziplines. Jonno peut uniquement se connecter à l’instance de Travel0 Adventure Management provisionnée pour créer et guider des aventures pour Suzie’s Rafting and Ziplines. Les informations d’identification de Jonno sont soit stockées dans une Database Connection associée au tenant 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. Cependant, comme elle n’a jamais été invitée à titre de 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 organisations parce que le guidage repose sur l’utilisation d’un système d’évaluation, et les évaluations de Sumana doivent être reportées et combinées entre les organisations avec lesquelles elle travaille. Les informations d’identification de Sumana, comme celles de Jonno, sont soit stockées dans une Database Connection associée au tenant 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 informations d’identification sont stockées n’a aucune incidence sur les instances d’organisation auxquelles elle a accès.

​

Accès administratif aux Organizations

Dans certains scénarios, vous devrez accorder un accès administratif à l’ensemble de vos Organizations. 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 il se peut que vous deviez accorder cet accès à vos employés ainsi qu’à des tiers.

Bonne pratique

Activez toujours l’authentification multifacteur (MFA) pour les administrateurs de tenant Auth0 qui obtiennent un accès par l’entremise de l’Auth0 Dashboard. Notez que vous devez suivre un processus différent pour activer la MFA pour un administrateur de tenant Auth0 que pour activer la MFA pour le tenant Auth0 lui-même. Pour savoir comment activer la MFA pour un administrateur de tenant 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 tenant Auth0. Vous pouvez même tirer parti de votre propre IdP d’entreprise pour permettre à vos employés de s’authentifier comme administrateurs de tenant Auth0, ainsi que pour accorder un accès d’administrateur de tenant étendu à des tiers de confiance.

Pour d’autres types d’accès administratif, vous voudrez généralement créer votre propre API ou votre propre application, que vous utiliserez conjointement avec la Management API d’Auth0. Il n’est pas recommandé d’offrir un accès administratif à votre tenant Auth0 au moyen de l’Auth0 Dashboard à un grand nombre d’utilisateurs. Bien que la création d’une telle application ou API dépasse la portée du présent document, il est recommandé de demander l’aide des Services professionnels d’Auth0 avant de vous lancer dans une telle initiative.

​

En savoir plus

• Organisations avec un seul fournisseur d’identité
• Organisations avec plusieurs fournisseurs d’identité