Fournisseur d’identités unique : provisionnement

Apprenez à provisionner les organisations pour les architectures multi-locataires.

En utilisant la fonctionnalité Auth0 Organizations, un seul locataire Auth0 peut être provisionné pour le déploiement dans un environnement de production. Pour tous les scénarios d’architecture, sauf les plus complexes, il est recommandé de fournir un seul locataire Auth0 à utiliser dans un environnement de production, pour faciliter l’intégration/l’utilisation de Authentification unique (SSO), la gestion du profil de l’utilisateur, et ainsi de suite. En fonction de l’implémentation, vous devrez traiter certains points supplémentaires concernant la configuration de votre locataire Auth0 et votre intégration correspondante.

La marque associée à une organisation est extrêmement précieuse, car elle fournit aux utilisateurs un environnement qu’ils connaissent et auquel ils font confiance. L’utilisation d’une marque reconnue renforce également la confiance des utilisateurs dans le fait que les informations qu’ils fournissent (par ex., leurs identifiants) seront traitées de manière sécurisée. La marque Auth0 par défaut doit donc être remplacée. Pour en savoir plus, consultez Image de marque.

​

Organisations

Vous devez créer une organisation Auth0 indépendante pour chacune des organisations concernées. Dans ce cas, nous créerons l’organisation hoekstra pour représenter Hoekstra & Associates dans notre exemple, et l’organisation metahexa pour représenter la banque MetaHexa. Vous pouvez créer des organisations, soit manuellement à partir du Auth0 Dashboard (Tableau de bord Auth0), soit par programmation en utilisant Management API Auth0.

​

Applications

En fonction de la manière dont est conçue l’implémentation de votre locataire d’organisation, différentes options s’offrent à vous lorsque vous créez des définitions Applications dans votre locataire Auth0. Quelle que soit l’option choisie, le comportement de l’organisation est défini au niveau de l’application.

Si vous provisionnez un locataire d’organisation distinct pour chacun de vos clients, vous devrez généralement disposer d’une définition d’application indépendante dans Auth0 pour chacun d’entre eux. Cet arrangement impliquera aussi généralement l’envoi à la fois du paramètre client_id spécifique à l’application et le paramètre organization, lequel identifie quelle organisation Auth0 à utiliser, dans le cadre de l’appel de point de terminaison /authorize. Pour en savoir plus, consultez Authentification.

Meilleure pratique

Pour faciliter la configuration et maximiser l’isolation de la sécurité, définissez les applications dans Auth0 de manière indépendante. Cela permet de configurer indépendamment des éléments tels que les URL de rappel autorisées et, conformément au principe du moindre privilège, de minimiser l’exposition potentielle de toute information relative à l’ID et au secret client.

Il est également possible d’utiliser une seule définition d’application dans Auth0. Dans ce cas, l’utilisateur sera invité à spécifier l’organisation requise dans le cadre de l’authentification à premier facteur. Cela nécessitera généralement l’utilisation d’un client_id d’application, mais le paramètre organization sera omis lors de l’appel au point de terminaison /authorize.

​

Connexions

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

Meilleure pratique

Pour les organisations à fournisseur d’identités unique (IdP), créez une connexion pour chaque organisation définie afin d’offrir une certaine flexibilité pour un certain nombre de scénarios d’utilisation. Par exemple, une seule connexion à une base de données ou base de données personnalisée par organisation vous permet de supprimer facilement les utilisateurs associés aux organisations qui sont déclassées et offre une flexibilité maximale aux organisations qui ont des exigences différentes en matière de complexité des mots de passe.

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

​

Utilisateurs

Les utilisateurs authentifiés via des connexions autres que des connexions de bases de données ou de bases de données personnalisées sont provisionnés auprès du fournisseur d’identités externe (IdP) indépendamment d’Auth0 et de manière normale. D’autre part, les utilisateurs authentifiés via une base de données ou des connexions de base de données personnalisées peuvent être provisionnés de différentes manières. Le Auth0 Dashboard et Management API Auth0 peuvent être utilisés pour créer un utilisateur directement dans votre locataire Auth0. Nous prenons aussi en charge la Migration automatique et la Migration en vrac.

Pour qu’un utilisateur puisse être provisionné via Management API ou le Tableau de bord, vous devez activer directement une base de données ou une connexion à une base de données personnalisée pour au moins une application. Activer une base de données ou une connexion à une base de données personnalisée pour une organisation seulement ne suffit pas.

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

Pour qu’un utilisateur puisse se voir attribuer manuellement le statut de membre d’une organisation, il doit déjà avoir un profil utilisateur défini dans Auth0. Vous pouvez affecter manuellement l’adhésion à l’aide du Tenant Dashboard Auth0 ou de Management API.

​

Invitation

La fonctionnalité Auth0 Organization (Organisation) permet également d’utiliser l’invitation des membres. Dans le flux de travail Member Invitation (Invitation des membres), l’invitation d’un utilisateur à une application entraînera le provisionnement automatique de l’utilisateur et la création automatique de son appartenance utilisateur.

​

Connexion à la base de données

Reprenons l’exemple de Hoekstra & Associates et voyons comment cette implémentation peut se dérouler lorsqu’une connexion à la base de données est utilisée dans le cadre de l’invitation utilisateur; la majeure partie du flux de travail décrit sera généralement gérée en utilisant la trousse SDK Auth0 ou la bibliothèque associée à votre infrastructure technologique :

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

   1. Le courriel a été envoyé tel que décrit dans l’Invite des membres de l’organisation et pourrait avoir été déclenché en utilisant l’Auth0 Dashboard ou le Management API Auth0.

2. Jennifer ouvre le courriel et clique sur le lien qu’il contient. Cela dirige son navigateur vers l’instance de Travel0 Corporate Booking de Hoekstra & Associates. L’URL de base utilisée dans le lien est spécifique à l’URI de connexion de l’application, qui fait partie de la définition de l’instance de l’application Travel0 Corporate Booking de Hoekstra & Associates dans le locataire Travel0 Auth0.

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

3. L’instance de Travel0 Corporate Booking de Hoekstra & Associates redirige le locataire Travel0 Auth0 Tenant à l’aide du Flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en passant les paramètres similaires au suivant, généralement en utilisant un Trousse SDK Auth0 ou 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é dans cette séance
   4. scope : openid profile…
   5. Toutes permissions OIDC supplémentaires nécessaires, en fonction des informations requises sur l’utilisateur.
   6. client_id : ID client associé à l’application créée dans le locataire Travel0 Auth0 pour l’instance de Travel0 Corporate Booking de Hoekstra & Associates.
   7. organization : Identifiant de l’organisation invitante, généralement obtenu via le lien dans le courriel décrit à l’étape 2. Spécifié de la façon suivante : organization=organization_id, où organization_id correspond à l’identifiant associé à la définition de l’organisation Auth0 correspondante dans votre locataire Auth0.
   8. invitation : Paramètre invitation supplémentaire associé au lien dans le courriel, comme décrit à l’étape 2.

4. Le locataire Travel0 Auth0 redirige vers /signup/invitation pour collecter un identifiant de mot de passe de l’utilisateur.

   1. Une page de connexion universelle, que vous pouvez configurer pour afficher des documents de marque propres à votre organisation, comme décrit dans la section Image de marque, est affichée.

      Le processus d’invitation associé à la fonctionnalité Auth0 Organizations ne prend pas en compte les sessions SSO (authentification unique) tenues avec Auth0. Si un utilisateur est invité à s’inscrire alors qu’il est déjà connecté, cliquer sur le lien dans le courriel affichera toujours la page de connexion universelle associée.

5. L’utilisateur saisit son mot de passe (et toute autre information d’identification, comme le nom d’utilisateur) et clique sur Continuer. L’ID de l’utilisateur est défini sur l’adresse courriel associée à l’utilisateur et ne peut pas être modifié.

6. Le locataire Travel0 Auth0 vérifie les identifiants. Si les informations sont valides, l’utilisateur est provisionné et l’appartenance à l’organisation Auth0 est définie. L’utilisateur est implicitement authentifié et le pipeline de Rules (Règles) s’exécute. Les Rules (Règles) peuvent être utilisées pour gérer le contrôle d’accès, comme décrit dans la section Authorization (Autorisation).

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

7. Une fois la vérification des informations d’identification et l’exécution des règles réussies, l’utilisateur est redirigé vers le redirect_uri (https://hoekstra.corp.travel0.net/login/callback) avec le state passé dans l’étape 3, ainsi qu’un code.

8. L’instance de Travel0 Corporate Booking de Hoekstra & Associates valide le state, puis appelle le locataire Travel0 Auth0 à https://auth.travel0.net/oauth/token, en passant le code et son ID client et son secret client en échange pour le jeton d’ID. Le jeton d’ID est ensuite utilisé pour générer une session sur https://hoekstra.corp.travel0.net.

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

​

Connexion d’entreprise

Reprenons l’exemple de la banque MetaHexa et voyons comment cette implémentation peut se dérouler lorsqu’une connexion d’entreprise est utilisée dans le cadre de l’invitation d’un utilisateur; là aussi, la plupart du flux de travail décrit sera généralement géré à l’aide da la trousse SDK Auth0 pertinente ou de la bibliothèque associée à votre pile technologique :

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

   1. Le courriel a été envoyé tel que décrit dans l’Invite des membres de l’organisation et pourrait avoir été déclenché en utilisant l’Auth0 Dashboard ou le Management API Auth0.

2. Amintha ouvre le courriel et clique sur le lien qu’il contient. Cela permet à son navigateur d’accéder à l’instance de Travel0 Corporate Booking de MetaHexa Bank. L’URL de base utilisée dans le lien est spécifié comme l’URI de connexion de l’application, qui fait partie de la définition de l’instance de l’application Travel0 Corporate Booking de MetaHexa Bank dans le locataire Travel0 Auth0.

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

3. L’instance de Travel0 Corporate Booking de MetaHexa Bank redirige vers le locataire Travel0 Auth0 à l’aide du Flux du code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en passant les paramètres similaires au suivant, généralement en utilisant une Trousse SDK Auth0 ou 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é dans cette séance
   4. scope : openid profile…
   5. Toutes permissions OIDC supplémentaires nécessaires, en fonction des informations requises sur l’utilisateur.
   6. client_id : ID client associé à l’application créée dans le locataire Travel0 Auth0 pour l’instance de MetaHexa Bank de Travel0 Corporate Booking.
   7. organization : Identifiant de l’organisation invitante, généralement obtenu via le lien dans le courriel décrit à l’étape 2. Spécifié de la façon suivante : organization=organization_id, où organization_id correspond à l’identifiant associé à la définition de l’organisation Auth0 correspondante dans votre locataire Auth0.
   8. invitation : Paramètre invitation supplémentaire associé au lien dans le courriel, comme décrit à l’étape 2.

4. Le locataire Travel0 Auth0 redirige vers /invitation, où Amintha est informée qu’elle sera redirigée vers l’IdP MetaHexa pour authentifier les identifiants à 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 et clique sur login (connexion).

5. En cas de succès, l’appartenance à l’organisation Auth0 est définie, l’utilisateur est implicitement authentifié et le pipeline de Rules (Règles) s’exécute. Les Rules (Règles) peuvent être utilisées pour gérer le contrôle d’accès, comme décrit dans la section Authorization (Autorisation).

Les étapes 6 à 8 correspondent à celles décrites dans le scénario Connexion à une base de données, mais où Amintha est l’utilisateur plutôt que Jennifer et où MetaHexa Bank (metahexa.corp.travel0.net) remplacera Hoekstra & Associates.

​

Connexion sociale

L’invitation via une connexions par les médias sociaux suit un schéma similaire à celui associé à une Enterprise Connection (Connexion d’entreprise), mais l’IdP en amont est associé au fournisseur social plutôt qu’à une organisation particulière. Pour un complément d’information sur l’utilisation des connexions sociales, veuillez consulter la section Authentification.