Comprendre le fonctionnement des organisations Auth0

La disponibilité varie selon le plan Auth0

L’implémentation propre à votre connexion et votre plan Auth0 ou accord personnalisé que vous utilisez déterminent si cette fonctionnalité est disponible. Pour en savoir plus, lisez Tarification.

Cas d’entreprise

La fonctionnalité Auth0 Organizations est la mieux adaptée aux implémentations interentreprises (B2B) dont les applications sont accessibles aux utilisateurs finaux.

Schéma d’analyse de rentabilité pour les organisations B2B

Les fonctionnalités courantes des implémentations B2B sont les suivantes :

  • Un produit dont la licence est concédée à une autre entreprise pour qu’elle l’utilise par ses employés.

  • Chaque organisation doit disposer de sa propre fédération et d’une stratégie de personnalisation allégée de l’expérience d’authentification.

  • Les niveaux d’accès dans l’application peuvent correspondre à des rôles attribués aux membres de chaque organisation.

Examinons quelques exemples de cas d’entreprise pour mettre en évidence la manière dont les organisations peuvent vous être utiles.

Exemple de scénario

Travel0 est une entreprise fictive qui propose des services de voyage en ligne et qui a configuré un locataire Auth0. Travel0 dispose de plusieurs applications, mais nous allons nous intéresser à une application qui pourrait bénéficier de l’utilisation d’Organizations.

Travel0 Adventure Management : Application en ligne qui permet à ses clients de créer et de commercialiser des aventures, comme le rafting en eaux vives, l’équitation et la tyrolienne. Chaque aventure est dirigée par un guide qui peut se servir de l’application pour s’inscrire et gérer la planification. Ces guides peuvent être employés directement par le client ou être indépendants.

Les clients de l’application sont notamment

  • Granite Outpost Rafting and Ziplines : Une entreprise bien établie qui emploie directement ses guides, mais qui fait parfois appel à des guides indépendants. Ils ont leur propre fournisseur d’identité (IdP) qu’ils utilisent pour leurs employés.

  • AdventureZ : Une importante société d’événementiel qui emploie directement un grand nombre de guides, mais qui fait également appel à des indépendants, quoique rarement. Elle encourage également ses employés directs à travailler comme indépendants pour d’autres entreprises en manque de guides. Ils ont leur propre fournisseur d’identité (IdP) qu’ils utilisent pour leurs employés.

  • Rocky Mountain High Adventures : Une nouvelle entreprise qui vient tout juste de se lancer sur le marché. Les cofondateurs organisent la plupart de leurs excursions et font appel à des indépendants pour les aider en période de pointe. Ils n’ont pas de personnel informatique et n’ont ni le temps ni l’envie de mettre en place leur propre fournisseur d’identité (IdP). Ils ont signé un contrat avec AdventureZ qui permet aux employés d’AdventureZ de travailler comme indépendants pour eux.

Considérations relatives à la planification

Lorsque vous mettez en place des organisations, tenez compte des éléments suivants :

  • Expérience de connexion : Les utilisateurs devront-ils sélectionner une organization lorsqu’ils se connectent? Les utilisateurs pourront-ils voir la page de connexion par défaut de l’application ou une page de connexion personnalisée pour leur organisation?

  • Modèle de connexion : Les organizations se partageront-elles les utilisateurs? Les utilisateurs doivent-ils avoir la possibilité de se connecter en utilisant le fournisseur d’identité interne de l’organisation?

  • Rôles : Les utilisateurs de l’application doivent-ils se voir attribuer des rôles spécifiques au sein de leur organization? Avez-vous l’intention de créer un tableau de bord personnalisé qui permette aux administrateurs de gérer eux-mêmes leur organisation en fonction des rôles qui leur sont attribués?

Expérience de connexion

Tout d’abord, vous devez déterminer l’expérience que doit avoir l’utilisateur lorsqu’il se connecte à une organisation. Vous pouvez choisir d’envoyer l’utilisateur final directement à l’invite de connexion d’une organisation spécifique dans Auth0, ou vous pouvez l’envoyer à une invite dans laquelle il peut saisir le nom de l’organisation avec laquelle il souhaite se connecter.

En outre, vous devez choisir d’utiliser la page de connexion universelle par défaut qui est configurée pour votre application ou de personnaliser une page de connexion spécifique à chaque organisation à l’aide de modèles de page. Pour en savoir plus, consultez Créez votre première Organization.

Modèle de connexion

Chaque organisation correspond généralement à l’un de vos clients ou partenaires commerciaux, bien que les utilisateurs puissent appartenir à plusieurs organisations. Comprendre comment les utilisateurs sont rattachés aux organisations clientes vous aidera à déterminer comment modéliser vos organisations et vos connexions. Il existe deux scénarios d’utilisation :

  • Les utilisateurs sont isolés dans une organization : Chaque utilisateur appartient à une seule organization. Les utilisateurs peuvent ne jamais avoir à appartenir à plusieurs organisations, ou alors il serait plus logique qu’ils créent une identité distincte pour chaque organisation.

  • Les utilisateurs sont partagés entre les organizations : Chaque utilisateur peut appartenir à plusieurs organizations et doit pouvoir utiliser la même identité pour naviguer d’une organization à l’autre.

Reprenons l’exemple de Travel0 Adventure Management et supposons que les utilisateurs suivants soient présents :

  • Jonno : Un guide directement employé par Rocky Mountain High Adventures et qui devrait être autorisé à se connecter uniquement à l’organization de Rocky Mountain. Ce dernier ne disposant pas de son propre IdP, les informations d’identification de Jonno sont stockées dans la connexion à la base de données Travel0 et Jonno se voit attribuer l’appartenance à l’organisation Rocky Mountain.

  • Hiroko : Un guide directement employé par Granite Outpost Rafting and Ziplines et qui devrait être autorisé à se connecter uniquement à l’organization de Granite Outpost. Comme Granite Outpost dispose de son propre IdP, les informations d’identification de Hiroko peuvent être stockées dans la connexion à la base de données Travel0 ou dans une connexion d’entreprise que Granite Outpost a mise en place pour représenter son IdP, après quoi Hiroko se verra également attribuer l’appartenance à l’organisation de Granite Outpost. En cas d’utilisation de l’IdP de Granite Outpost, la connexion d’entreprise doit également être activée pour l’organisation.

  • Emilio : Un guide qui travaille en indépendant pour Rocky Mountain High Adventures et Granite Outpost Rafting and Ziplines et qui devrait être autorisé à se connecter aux deux organizations. Si nous voulons permettre à Emilio d’utiliser les mêmes informations d’identification pour les deux organisations, les informations d’identification d’Emilio doivent être stockées dans la connexion à la base de données Travel0, et Emilio doit appartenir à la fois à l’organisation Rocky Mountain et à l’organisation Granite Outpost. Dans le cas contraire, Emilio devra définir un ensemble d’informations d’identification dans la connexion à la base de données Travel0 pour Rocky Mountain High Adventures et appartenir à l’organisation Rocky Mountain High, puis définir un autre ensemble d’informations d’identification dans la connexion à la base de données Travel0 ou dans la connexion d’entreprise de Granite Outpost et appartenir à l’organisation Granite Outpost. Pour finir, si vous utilisez l’IdP de Granite Outpost, la connexion d’entreprise configurée doit être activée pour l’organisation de Granite Outpost.

  • Sumana : Une guide qui est directement employée par AdventureZ, mais qui travaille parfois en indépendant pour Rocky Mountain High Adventures dans le cadre du contrat conclu entre Rocky Mountain et AdventureZ. AdventureZ et Rocky Mountain ont des systèmes d’évaluation pour leurs guides, ce qui signifie que les évaluations de Sumana doivent être transférées d’AdventureZ à Rocky Mountain et être combinées entre les deux organisations. Soit les informations d’identification de Sumana sont stockées dans la connexion à la base de données Travel0 et l’appartenance est attribuée aux organisations Rocky Mountain et AdventureZ, soit, si AdventureZ souhaite partager son IdP, les informations d’identification de Sumana sont stockées dans une connexion d’entreprise qu’AdventureZ a établie pour représenter son IdP et la connexion d’entreprise configurée est activée à la fois pour les organisations Rocky Mountain et AdventureZ. Si Sumana est également invitée à travailler en indépendante pour Granite Outpost Rafting and Ziplines, ses informations d’identification peuvent être stockées dans la connexion à la base de données Travel0 ou elle peut être ajoutée à l’IdP de Granite Outpost, et son appartenance doit être attribuée à l’organisation Granite Outpost.

Une fois que vous avez déterminé le nombre d’organizations et le modèle de connexion, vous pouvez établir des connexions de base de données, social, ou entreprise; créer des organizations; et configuration de l’appartenance à une organization ou activer les connexions d’organization.

Rôles

Les membres des organizations peuvent se voir attribuer des rôles. Vous pouvez utiliser ces rôles pour définir le contrôle d’accès à votre application. Par exemple, si vous avez créé un tableau de bord pour vos utilisateurs à l’aide de notre API et de nos trousses SDK, vous pouvez attribuer un rôle d’administrateur à certains membres et leur permettre de gérer eux-mêmes leur organisation par le biais de votre tableau de bord.

Limites

La fonctionnalité Auth0 Organizations présente les limites suivantes :

  • Votre plan d’abonnement Auth0 influe sur la disponibilité de cette fonctionnalité. Pour en savoir plus, veuillez consulter Tarification Auth0.

  • Pris en charge uniquement pour la Connexion universelle (non pris en charge pour la Connexion classique ou Lock.js).

  • Les applications compatibles avec les organizations ne sont pas compatibles avec les octrois et les protocoles suivants : Mot de passe de propriétaire de ressource, identifiants clients, Flux d’autorisation d'appareils, WS-Fed (Auth0 en tant qu’IdP).

  • Ne prend pas en charge :

    • Domaines personnalisés par organization (Par exemple, en utilisant le scénario type, si Rocky Mountain High Adventures et Granite Outpost Rafting et Ziplining pouvaient tous deux utiliser login.travel0.com comme domaines de connexion, alors les organizations seraient utiles. Autrement, si Rocky Mountain High Adventures voulait utiliser login.rockymountain.com et Granite Outpost voulait utiliser login.graniteoutpost.com, vous auriez alors besoin d’utiliser plusieurs locataires Auth0.

    • Intégration avec l’extension de l’administration déléguée.

    • Intégration avec Authorization Extension.

    • Intégration avec des applications tierces.

En savoir plus