> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Découvrez le provisionnement des Organizations pour les architectures multitenantes.
# Single Identity Provider: Provisioning
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)](/docs/fr-ca/authenticate/single-sign-on), de la [gestion des profils](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management) 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](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/branding).
## 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](/docs/fr-ca/manage-users/organizations/configure-organizations/create-organizations) 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](/docs/fr-ca/get-started/applications) dans votre tenant Auth0. Quelle que soit l’option choisie, l’[organization behavior est défini au niveau de l’application](/docs/fr-ca/manage-users/organizations/configure-organizations/define-organization-behavior).
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](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/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](/docs/fr-ca/authenticate/identity-providers) qui serviront à authentifier les utilisateurs. Dans ce cas, nous définirons une [connexion de base de données](/docs/fr-ca/authenticate/database-connections) pour les utilisateurs associés à Hoekstra & Associates et une [connexion d’entreprise](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers) 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](/docs/fr-ca/authenticate/database-connections) 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](/docs/fr-ca/manage-users/organizations/configure-organizations/enable-connections).
## 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](/docs/fr-ca/manage-users/user-migration/configure-automatic-migration-from-your-database) et la [migration en bloc](/docs/fr-ca/manage-users/user-migration/bulk-user-imports).
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](/docs/fr-ca/manage-users/organizations/configure-organizations/grant-just-in-time-membership) ou [manuellement](/docs/fr-ca/manage-users/organizations/configure-organizations/assign-members).
Pour qu’une appartenance à une organisation soit attribuée manuellement à un utilisateur, cet utilisateur doit déjà avoir un [profil d’utilisateur](/docs/fr-ca/manage-users/user-accounts/user-profiles) défini dans Auth0. Vous pouvez [attribuer manuellement une appartenance](/docs/fr-ca/manage-users/organizations/configure-organizations/assign-members) 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](/docs/fr-ca/manage-users/organizations/configure-organizations/invite-members) 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](/docs/fr-ca/get-started/applications/application-settings), 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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) (avec ou sans [PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-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](/docs/fr-ca/libraries) ou d’une bibliothèque tierce :
1. `redirect_uri` : [`https://hoekstra.corp.travel0.net/login/callback`](https://hoekstra.corp.travel0.net/login/callback)
2. `response_type` : `code`
3. `state` : [state](/docs/fr-ca/secure/attack-protection/state-parameters) unique généré pour cette session
4. `scope` : `openid profile` ...
5. tout [scope OIDC](/docs/fr-ca/get-started/apis/scopes/openid-connect-scopes) 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](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/branding), 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](/docs/fr-ca/customize/rules) s’exécute. Les Rules peuvent servir à gérer le contrôle d’accès, comme décrit dans [Authorization](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/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`](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`](https://auth.travel0.net/oauth/token), en transmettant le `code` ainsi que son `client id` et son `client secret` en échange du [ID Token](/docs/fr-ca/secure/tokens/id-tokens). Le ID Token est ensuite utilisé pour générer une session pour [`https://hoekstra.corp.travel0.net`](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](/docs/fr-ca/manage-users/organizations/configure-organizations/invite-members) 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](/docs/fr-ca/get-started/applications/application-settings), 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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) (avec ou sans [PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-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](/docs/fr-ca/libraries) ou d’une bibliothèque tierce :
1. `redirect_uri`: [`https://metahexa.corp.travel0.net/login/callback`](https://metahexa.corp.travel0.net/login/callback)
2. `response_type`: `code`
3. `state`: [state](/docs/fr-ca/secure/attack-protection/state-parameters) unique généré pour cette session
4. `scope`: `openid profile` ...
5. tout [scope OIDC](/docs/fr-ca/get-started/apis/scopes/openid-connect-scopes) 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](/docs/fr-ca/customize/rules) s’exécute. Les Rules peuvent être utilisées pour gérer le contrôle d’accès comme décrit dans [Authorization](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization).
Les étapes 6 à 8 correspondront à celles décrites dans le scénario [Connexion de base de données](#database-connection), 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](#enterprise-connections), 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](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authentication).