Single Identity Provider: Provisioning

Découvrez le provisionnement des Organizations pour les architectures multitenantes.

Grâce à la fonctionnalité Auth0 Organizations, il est possible de provisionner un seul tenant Auth0 pour le déployer dans un environnement de production. Sauf dans les scénarios d’architecture les plus complexes, il est recommandé de provisionner un seul tenant Auth0 pour une utilisation dans un environnement de production, car cela facilite l’intégration et l’utilisation du Single Sign-On (SSO), de la gestion des profils des utilisateurs, etc. Selon la mise en œuvre, vous devrez aussi tenir compte de certains éléments supplémentaires liés à la configuration de votre tenant Auth0 et de l’intégration correspondante.

L’image de marque associée à une organization est extrêmement précieuse, car l’utilisation d’éléments d’image de marque offre aux utilisateurs un environnement qu’ils connaissent et auquel ils font confiance. L’utilisation d’éléments d’image de marque reconnus renforce aussi la confiance des utilisateurs quant au traitement sûr et sécuritaire des renseignements qu’ils fournissent (par exemple, des informations d’authentification). L’image de marque Auth0 par défaut devrait donc être remplacée. Pour en savoir plus, consultez Image de marque.

​

Organisations

Vous devriez créer une Auth0 organisation distincte pour chacune des organisations que vous gérerez. Dans ce cas, nous créerons l’organisation hoekstra pour représenter Hoekstra & Associates dans notre exemple, et l’organisation metahexa pour représenter MetaHexa Bank. Vous pouvez créer des organisations soit manuellement dans le Auth0 Dashboard, soit par programmation à l’aide de la Management API.

​

Applications

Selon la conception de la mise en œuvre de votre tenant organisation, vous disposez de différentes options pour créer des définitions d’Application dans votre tenant Auth0. Quelle que soit l’option choisie, l’organization behavior est défini au niveau de l’application.

Si vous provisionnez un tenant organisation distinct pour chacun de vos clients, vous aurez généralement besoin d’une définition d’Application distincte dans Auth0 pour chacun d’eux. Cette approche implique aussi habituellement l’envoi du paramètre client_id propre à l’Application ainsi que du paramètre organization, qui indique quelle Auth0 organisation utiliser, dans le cadre de la requête vers le endpoint /authorize. Pour en savoir plus, consultez Authentication.

Bonne pratique

Pour simplifier la configuration et maximiser l’isolation de sécurité, définissez les Applications dans Auth0 de façon distincte. Cela permet de configurer séparément des éléments comme les callback URLs autorisées et, conformément au principe du moindre privilège, de réduire au minimum l’exposition potentielle de toute information liée au Client ID et au Client Secret.

Autrement, l’utilisation d’une seule définition d’Application dans Auth0 est prise en charge. Dans ce cas, l’utilisateur sera invité à préciser l’organisation requise dans le cadre de l’authentication de premier facteur. Cela nécessitera généralement l’utilisation d’un client_id d’Application commun, mais le paramètre organization sera omis de la requête vers le endpoint /authorize.

​

Connexions

Ensuite, définissez les connexions qui serviront à authentifier les utilisateurs. Dans ce cas, nous définirons une connexion de base de données pour les utilisateurs associés à Hoekstra & Associates et une connexion d’entreprise pour les utilisateurs associés à MetaHexa Bank.

Bonne pratique

Pour les organisations à fournisseur d’identité unique (IdP), créez une connexion pour chaque organisation définie afin d’offrir la souplesse nécessaire à divers cas d’utilisation. Par exemple, une seule connexion de base de données ou connexion de base de données personnalisée par organisation vous permet de supprimer facilement les utilisateurs associés aux organisations mises hors service et offre un maximum de souplesse pour les organisations ayant des exigences différentes en matière de complexité des mots de passe.

Une fois la connexion définie, elle peut être attribuée à l’organisation Auth0 appropriée à l’aide de l’Auth0 Dashboard ou de l’Auth0 Management API. Pour en savoir plus, consultez Activer les connexions d’organisation.

​

Utilisateurs

Pour les utilisateurs authentifiés au moyen de Connections autres que Database ou connexions de base de données personnalisées, l’utilisateur est provisionné dans le fournisseur d’identité (IdP) externe, indépendamment d’Auth0, de la manière habituelle. En revanche, les utilisateurs authentifiés au moyen de Database ou de connexions de base de données personnalisées peuvent être provisionnés de différentes façons. L’Auth0 Dashboard et l’Auth0 Management API peuvent être utilisés pour créer un utilisateur directement dans votre tenant Auth0. Nous prenons aussi en charge la migration automatique et la migration en bloc.

Pour qu’un utilisateur soit provisionné au moyen de l’Auth0 Management API ou de l’Auth0 Dashboard, vous devez activer directement une Database ou connexion de base de données personnalisée pour au moins une application. Il ne suffit pas d’activer une Database ou connexion de base de données personnalisée uniquement pour une organisation.

Les utilisateurs sont ensuite associés à une organisation Auth0 en leur attribuant des appartenances, et une organisation Auth0 peut être configurée pour attribuer automatiquement l’appartenance d’un utilisateur ou manuellement.

Pour qu’une appartenance à une organisation soit attribuée manuellement à un utilisateur, cet utilisateur doit déjà avoir un profil d’utilisateur défini dans Auth0. Vous pouvez attribuer manuellement une appartenance au moyen du Dashboard du tenant Auth0 ou de l’Auth0 Management API.

​

Invitation

La fonctionnalité Auth0 organisation prend aussi en charge l’utilisation des invitations de membres. Dans le flux de travail d’invitation de membres, le fait d’inviter un utilisateur à une application fait en sorte que l’utilisateur soit provisionné automatiquement et que son appartenance soit créée automatiquement.

​

connexion de base de données

En reprenant notre exemple de Hoekstra & Associates, voyons comment cette mise en œuvre peut se dérouler lorsqu’une connexion de base de données est utilisée dans le cadre d’une invitation d’utilisateur; la plus grande partie du processus décrit est généralement prise en charge par l’Auth0 SDK pertinent ou par la bibliothèque associée à votre pile technologique :

1. Jennifer, de Hoekstra & Associates, reçoit un courriel envoyé par le tenant Auth0 de Travel0 au nom de l’instance Travel0 Corporate Booking de Hoekstra & Associates.

   1. Le courriel a été envoyé comme décrit dans Inviter des membres d’organisation et pourrait avoir été déclenché depuis l’Auth0 Dashboard ou l’Auth0 Management API.

2. Jennifer ouvre le courriel et clique sur le lien qu’il contient. Ce faisant, son navigateur est redirigé vers l’instance de Travel0 Corporate Booking de Hoekstra & Associates. L’URL de base utilisée dans le lien est définie comme l’URI de connexion de l’application, qui fait partie de la définition de l’application Travel0 Corporate Booking dans le tenant Auth0 Travel0 de Hoekstra & Associates.

   1. Le lien contient les paramètres organization et organization_name. Le paramètre organization est défini sur l’ID de la définition Auth0 Organization correspondante dans votre tenant Auth0. Celui-ci sera transmis au tenant Auth0 à l’étape 3.
   2. Le lien contient également le paramètre invitation, qui sera lui aussi transmis à l’étape 3.

3. L’instance Travel0 Corporate Booking de Hoekstra & Associates redirige vers le tenant Auth0 de Travel0 à l’aide du flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en lui transmettant des paramètres semblables à ceux-ci, généralement à l’aide d’un Auth0 SDK ou d’une bibliothèque tierce :

   1. redirect_uri : https://hoekstra.corp.travel0.net/login/callback
   2. response_type : code
   3. state : state unique généré pour cette session
   4. scope : openid profile …
   5. tout scope OIDC supplémentaire nécessaire, selon les renseignements requis sur l’utilisateur.
   6. client_id : Client ID associé à l’Application créée dans le tenant Auth0 Travel0 pour l’instance de Travel0 Corporate Booking de Hoekstra & Associates.
   7. organization : ID de l’organization invitante, généralement obtenu à partir du lien dans le courriel décrit à l’étape 2. Indiqué sous la forme organization=organization_id, où organization_id correspond à l’identifiant associé à la définition d’Auth0 Organization correspondante dans votre tenant Auth0.
   8. invitation : paramètre invitation supplémentaire associé au lien dans le courriel, comme décrit à l’étape 2.

4. Le tenant Auth0 de Travel0 redirige vers /signup/invitation pour permettre à l’utilisateur de définir un mot de passe.

   1. Une Universal Login Page, que vous pouvez configurer pour afficher des éléments d’image de marque propres à l’organisation, comme décrit dans Image de marque, s’affiche.

      Le workflow d’invitation associé à la fonctionnalité Auth0 Organizations ne tient compte d’aucune session SSO active auprès d’Auth0. Si un utilisateur est invité à s’inscrire alors qu’il est déjà connecté, le fait de cliquer sur le lien dans le courriel affichera toujours la Universal Login Page associée.

5. L’utilisateur saisit son mot de passe (ainsi que tout renseignement d’authentification supplémentaire, comme son nom d’utilisateur) et clique sur Continuer. L’ID utilisateur correspond à l’adresse courriel associée à l’utilisateur et ne peut pas être modifié.

6. Le tenant Auth0 Travel0 vérifie les identifiants. S’ils sont valides, l’utilisateur est provisionné et son appartenance à l’Auth0 Organization est établie. L’utilisateur est authentifié de façon implicite, et le pipeline Rules s’exécute. Les Rules peuvent servir à gérer le contrôle d’accès, comme décrit dans Authorization.

   1. Si les identifiants de l’utilisateur ne sont pas valides, l’utilisateur sera alors invité à les saisir à nouveau.

7. Après la validation des identifiants et l’exécution des Rules, l’utilisateur est redirigé vers le redirect_uri (https://hoekstra.corp.travel0.net/login/callback) avec le state transmis à l’étape 3, ainsi qu’un code.

8. L’instance de Travel0 Corporate Booking de Hoekstra & Associates valide le state, puis fait une requête au tenant Auth0 de Travel0 à l’adresse https://auth.travel0.net/oauth/token, en transmettant le code ainsi que son client id et son client secret en échange du ID Token. Le ID Token est ensuite utilisé pour générer une session pour https://hoekstra.corp.travel0.net.

9. L’instance de Travel0 Corporate Booking de Hoekstra & Associates affiche ensuite la page appropriée à l’utilisateur.

​

Connexion d’entreprise

En reprenant notre exemple de MetaHexa Bank, voyons comment cette mise en œuvre peut se dérouler lorsqu’une Connexion d’entreprise est utilisée dans le cadre d’une invitation d’utilisateur; encore une fois, la majeure partie du flux de travail décrit sera généralement prise en charge grâce à l’Auth0 SDK approprié ou à la bibliothèque associée à votre pile technologique :

1. Amintha de MetaHexa Bank reçoit un courriel envoyé depuis le tenant Auth0 de Travel0 au nom de l’instance de Travel0 Corporate Booking de MetaHexa Bank.

   1. Le courriel a été envoyé comme décrit dans Inviter des membres d’une organisation et peut avoir été déclenché à partir de l’Auth0 Dashboard ou de l’Auth0 Management API.

2. Amintha ouvre le courriel et clique sur le lien qu’il contient. Cela dirige son navigateur vers l’instance de Travel0 Corporate Booking de MetaHexa Bank. L’URL de base utilisée dans le lien correspond à l’Application Login URI, qui fait partie de la définition de l’application de l’instance de Travel0 Corporate Booking de MetaHexa Bank dans le tenant Auth0 de Travel0.

   1. Le lien contient les paramètres organization et organization_name. Le paramètre organization correspond à l’ID de la définition Auth0 organisation correspondante dans votre tenant Auth0. Il sera transmis au tenant Auth0 à l’étape 3.
   2. Le lien contient aussi le paramètre invitation, qui sera également transmis à l’étape 3.

3. L’instance de Travel0 Corporate Booking de MetaHexa Bank redirige vers le tenant Auth0 de Travel0 en utilisant le flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en transmettant des paramètres semblables aux suivants, habituellement par l’intermédiaire d’un Auth0 SDK ou d’une bibliothèque tierce :

   1. redirect_uri: https://metahexa.corp.travel0.net/login/callback
   2. response_type: code
   3. state: state unique généré pour cette session
   4. scope: openid profile …
   5. tout scope OIDC supplémentaire nécessaire, selon les renseignements requis au sujet de l’utilisateur.
   6. client_id: Client ID associé à l’Application créée dans le tenant Auth0 de Travel0 pour l’instance de Travel0 Corporate Booking de MetaHexa Bank.
   7. organization: ID de l’organisation invitante, habituellement obtenu au moyen du lien dans le courriel décrit à l’étape 2. Il est indiqué sous la forme organization=organization_id, où organization_id correspond à l’identificateur associé à la définition Auth0 organisation correspondante dans votre tenant Auth0.
   8. invitation: Paramètre invitation supplémentaire associé au lien dans le courriel, comme décrit à l’étape 2.

4. Le tenant Auth0 de Travel0 redirige vers /invitation, où Amintha est informée qu’elle sera redirigée vers le IdP de MetaHexa pour s’authentifier à l’aide de ses identifiants de premier facteur.

   1. L’utilisateur confirme, et
   2. Auth0 redirige vers l’instance IdP de MetaHexa Bank, où
   3. La page de connexion s’affiche, et l’utilisateur saisit ses identifiants puis clique sur login.

5. Si l’opération réussit, l’appartenance à l’Auth0 organisation est établie, l’utilisateur est implicitement authentifié, et le pipeline Rules s’exécute. Les Rules peuvent être utilisées pour gérer le contrôle d’accès comme décrit dans Authorization.

Les étapes 6 à 8 correspondront à celles décrites dans le scénario Connexion de base de données, mais avec Amintha comme utilisatrice plutôt que Jennifer, et MetaHexa Bank (metahexa.corp.travel0.net) à la place de Hoekstra & Associates.

​

Connexion sociale

L’invitation par Connexion sociale suit un modèle semblable à celui d’une Connexion d’entreprise, mais l’IdP en amont est associé au fournisseur social plutôt qu’à une organisation en particulier. Pour connaître d’autres points à prendre en compte lors de l’utilisation des Connexions sociales, consultez Authentification.