Passer au contenu principal

La disponibilité varie selon votre forfait Auth0

Votre implémentation de connexion ainsi que votre forfait Auth0 ou votre entente personnalisée déterminent si cette fonctionnalité est offerte. Pour en savoir plus, consultez Tarification.

​
Cas d’utilisation

La fonctionnalité Organisations d’Auth0 est particulièrement bien adaptée aux implémentations interentreprises (B2B) dans lesquelles les utilisateurs finaux accèdent à des applications.
Diagramme du cas d’utilisation B2B des organisations
Les caractéristiques courantes des implémentations B2B comprennent :
  • Un produit concédé sous licence à une autre entreprise pour être utilisé par ses employés.
  • Chaque organisation nécessite sa propre fédération et une image de marque légère pour l’expérience d’authentification.
  • Les niveaux d’accès dans l’application peuvent être représentés par des rôles attribués aux membres de chaque organisation.
Examinons quelques exemples de cas d’utilisation pour illustrer comment les Organisations peuvent aider.

​
Exemple de scénario

Travel0 est une entreprise fictive qui offre des services de voyage en ligne et qui a configuré un locataire Auth0. Travel0 possède plusieurs applications, mais nous allons nous concentrer sur une application qui pourrait tirer parti des organisations. Travel0 Adventure Management : une application en ligne qui permet à ses clients de créer et de promouvoir des aventures, comme le rafting en eaux vives, l’équitation et la tyrolienne. Chaque aventure est dirigée par un guide qui peut utiliser l’application pour s’inscrire et gérer les horaires. Les guides peuvent être soit employés directement par le client, soit pigistes. Les clients de l’application comprennent :
  • Granite Outpost Rafting and Ziplines : une entreprise bien établie qui emploie directement un grand nombre de guides, mais qui fait aussi parfois appel à des guides pigistes. Elle dispose de son propre qu’elle utilise pour ses employés.
  • AdventureZ : une grande entreprise événementielle qui emploie directement un grand nombre de guides, mais qui fait aussi appel à des pigistes, quoique rarement. Elle permet également à ses employés de travailler comme pigistes pour d’autres entreprises qui ont besoin de guides. Elle dispose de son propre IdP qu’elle utilise pour ses employés.
  • Rocky Mountain High Adventures : une nouvelle entreprise qui arrive tout juste sur le marché. Les cofondateurs dirigent la plupart de leurs excursions et font appel à des pigistes pendant les périodes plus achalandées. Ils n’ont pas d’équipe TI et n’ont ni le temps ni l’envie de configurer leur propre fournisseur d’identité (IdP). Ils ont un contrat avec AdventureZ qui permet à tout employé d’AdventureZ de travailler comme pigiste pour eux.

​
Considérations relatives à la planification

Lors de la configuration des organisations, tenez compte des éléments suivants :
  • Expérience de connexion : Les utilisateurs devront-ils sélectionner une organisation au moment de se connecter ? Verront-ils la page de connexion par défaut de l’application ou une page de connexion personnalisée pour leur organisation ?
  • Modèle de connexion : Certains utilisateurs seront-ils partagés entre plusieurs organisations ? Les utilisateurs doivent-ils pouvoir se connecter à l’aide du fournisseur d’identité interne de leur organisation ?
  • Rôles : L’application exige-t-elle que des rôles précis soient attribués aux utilisateurs au sein de leur organisation ? Prévoyez-vous créer un tableau de bord personnalisé permettant aux administrateurs de gérer eux-mêmes leurs organisations à l’aide des rôles attribués ?

​
Expérience de connexion

Vous devez d’abord déterminer l’expérience que l’utilisateur aura lorsqu’il se connectera à une organisation. Vous pouvez choisir d’envoyer l’utilisateur final directement vers l’invite de connexion d’une Organisation précise dans Auth0, ou de l’envoyer vers une invite où il pourra saisir le nom de l’Organisation à laquelle il souhaite se connecter. De plus, vous devez choisir si vous utilisez la page par défaut configurée pour votre application, ou si vous personnalisez une page de connexion propre à chaque organisation à l’aide de modèles de page. Pour en savoir plus, consultez Créer votre première organisation.

​
Modèle de connexion

Chaque organisation correspond généralement directement à l’un de vos clients ou partenaires commerciaux, mais les utilisateurs peuvent être membres de plusieurs organisations. Comprendre comment les utilisateurs s’associent aux organisations clientes vous aidera à déterminer comment modéliser vos organisations et vos connexions. Il existe deux scénarios pour les utilisateurs :
  • Les utilisateurs sont limités à une organisation : Chaque utilisateur est membre d’une seule organisation. Soit les utilisateurs n’auront jamais besoin de faire partie de plusieurs organisations, soit il serait plus logique qu’ils créent une identité distincte pour chaque organisation.
  • Les utilisateurs sont partagés entre plusieurs organisations : Tout utilisateur peut appartenir à plusieurs organisations et devrait pouvoir utiliser la même identité pour passer d’une organisation à l’autre.
Prenons l’exemple de Travel0 Adventure Management et supposons les utilisateurs suivants :
  • Jonno : Un guide employé directement par Rocky Mountain High Adventures, qui ne devrait pouvoir se connecter qu’à l’organisation Rocky Mountain. Comme Rocky Mountain n’a pas son propre IdP, les identifiants de Jonno sont stockés dans la connexion de base de données Travel0, et Jonno se voit attribuer une appartenance à l’organisation Rocky Mountain.
  • Hiroko : Une guide employée directement par Granite Outpost Rafting and Ziplines, qui ne devrait pouvoir se connecter qu’à l’organisation Granite Outpost. Comme Granite Outpost a son propre IdP, les identifiants de Hiroko peuvent être stockés soit dans la connexion de base de données Travel0, soit dans une connexion d’entreprise que Granite Outpost a configurée pour représenter son IdP, et Hiroko doit aussi se voir attribuer une appartenance à l’organisation Granite Outpost. Si vous utilisez l’IdP de Granite Outpost, la connexion d’entreprise doit aussi être activée pour l’organisation.
  • Emilio : Un guide pigiste qui travaille à la fois pour Rocky Mountain High Adventures et Granite Outpost Rafting and Ziplines, et qui devrait pouvoir se connecter aux deux organisations. Si nous voulons qu’Emilio puisse utiliser les mêmes identifiants pour les deux organisations, ses identifiants devraient être stockés dans la connexion de base de données Travel0, et Emilio devrait se voir attribuer une appartenance aux organisations Rocky Mountain et Granite Outpost. Sinon, Emilio devra configurer un ensemble d’identifiants dans la connexion de base de données Travel0 pour Rocky Mountain High Adventures et se voir attribuer une appartenance à l’organisation Rocky Mountain High, puis configurer un autre ensemble d’identifiants soit dans la connexion de base de données Travel0, soit dans la connexion d’entreprise de Granite Outpost, et se voir attribuer une appartenance à l’organisation Granite Outpost. Enfin, si vous utilisez l’IdP de Granite Outpost, la connexion d’entreprise configurée doit être activée pour l’organisation Granite Outpost.
  • Sumana : Une guide employée directement par AdventureZ, mais qui travaille parfois comme pigiste pour Rocky Mountain High Adventures dans le cadre du contrat entre Rocky Mountain et AdventureZ. AdventureZ et Rocky Mountain ont des systèmes d’évaluation pour leurs guides, et les évaluations de Sumana doivent être transférées d’AdventureZ à Rocky Mountain et combinées entre les organisations. Soit les identifiants de Sumana devraient être stockés dans la connexion de base de données Travel0 et une appartenance devrait lui être attribuée pour les organisations Rocky Mountain et AdventureZ, soit, si AdventureZ veut partager son IdP, les identifiants de Sumana devraient être stockés dans une connexion d’entreprise qu’AdventureZ a configurée pour représenter son IdP, et la connexion d’entreprise configurée doit être activée pour les organisations Rocky Mountain et AdventureZ. Si Sumana est aussi invitée à travailler comme pigiste pour Granite Outpost Rafting and Ziplines, ses identifiants pourraient alors être stockés dans la connexion de base de données Travel0, ou elle pourrait être ajoutée à l’IdP de Granite Outpost, et une appartenance devrait lui être attribuée à l’organisation Granite Outpost.
Une fois que vous avez déterminé combien d’organisations vous aurez et à quoi devrait ressembler votre modèle de connexion, vous pouvez configurer des connexions de base de données, sociales ou d’entreprise, créer des organisations et configurer l’appartenance à une organisation ou activer des connexions d’organisation.

​
Rôles

Les membres d’organisations 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 SDK, vous pourriez attribuer un rôle d’administrateur à certains membres et leur permettre de gérer eux-mêmes leur organisation depuis votre tableau de bord.
La Management API ne doit être accessible qu’au moyen d’une application confidentielle. Son utilisation est assujettie aux limites de débit de la Management API d’Auth0.

​
Limitations

La fonctionnalité Organisations d’Auth0 présente les limitations suivantes :
  • Votre abonnement Auth0 a une incidence sur la disponibilité de cette fonctionnalité. Pour en savoir plus, consultez Auth0 Pricing.
  • Pris en charge uniquement avec Universal Login (non pris en charge avec Classic Login ou Lock.js).
  • Les applications pour lesquelles Organisations est activé ne sont pas compatibles avec les types d’octroi et protocoles suivants : Password, Device , (Auth0 en tant qu’IdP).
  • Ne prend pas en charge :
    • Les domaines personnalisés par organisation (Par exemple, dans ce scénario, si Rocky Mountain High Adventures et Granite Outpost Rafting and Ziplining pouvaient tous deux utiliser login.travel0.com comme domaine de connexion, la fonctionnalité Organisations serait utile. En revanche, si Rocky Mountain High Adventures voulait utiliser login.rockymountain.com et Granite Outpost voulait utiliser login.graniteoutpost.com, vous devriez utiliser plusieurs locataires Auth0.
    • L’intégration à la Delegated Administration Extension.
    • L’intégration à la Authorization Extension.
    • L’intégration à des applications tierces.

​
En savoir plus