Skip to main content

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’usage commerciaux

La fonctionnalité Auth0 Organizations convient particulièrement bien aux mises en œuvre interentreprises (B2B) comportant des applications auxquelles les utilisateurs finaux accèdent.
Diagramme de cas d’usage commercial B2B Organizations
Les caractéristiques courantes des mises en œuvre B2B comprennent :
  • Un produit offert sous licence à une autre entreprise pour être utilisé par ses employés.
  • Chaque organisation a besoin de sa propre fédération et d’une personnalisation légère de l’expérience d’authentification à son image.
  • Les niveaux d’accès dans l’application peuvent être représentés par des rôles attribués aux membres de chaque organisation.
Voyons quelques exemples de cas d’usage commerciaux pour illustrer de quelles façons Organizations peut aider.

​
Exemple de scénario

Travel0 est une entreprise fictive qui offre des services de voyage en ligne et qui a mis en place un tenant Auth0. Travel0 a plusieurs applications, mais nous nous concentrerons sur une application qui pourrait bénéficier de l’utilisation d’Organizations. 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 les descentes en tyrolienne. Chaque aventure est encadrée par un guide, qui peut utiliser l’application pour s’inscrire et gérer l’horaire. Les guides peuvent être soit des employés du client, soit des 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 possède son propre , qu’elle utilise pour ses employés.
  • AdventureZ : Une grande entreprise d’événementiel 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 possè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 de personnel TI et n’ont ni le temps ni l’envie de mettre en place 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 de 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 ? Envisagez-vous de 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écider de l’expérience que l’utilisateur vivra lorsqu’il se connectera à une organization. Vous pouvez choisir d’envoyer l’utilisateur final directement vers le prompt de connexion d’une organization précise dans Auth0, ou de l’envoyer vers un prompt où il pourra entrer le nom de l’organization à laquelle il souhaite se connecter. Vous devez également choisir si vous voulez utiliser la page par défaut configurée pour votre application, ou personnaliser une page de connexion propre à chaque organization à l’aide de modèles de page. Pour en savoir plus, consultez Créer votre première organization.

​
Modèle de connexion

Chaque Organizations correspond généralement directement à l’un de vos clients ou partenaires commerciaux, mais les utilisateurs peuvent être membres de plusieurs Organizations. Comprendre comment les utilisateurs se rattachent aux Organizations clientes vous aidera à déterminer comment modéliser vos Organizations et vos connexions. Il existe deux scénarios d’utilisateurs :
  • Les utilisateurs sont limités à une Organizations : Chaque utilisateur est membre d’exactement une Organizations. Soit les utilisateurs n’auront jamais besoin de faire partie de plusieurs Organizations, soit il sera plus logique pour eux de créer une identité distincte pour chaque Organizations.
  • Les utilisateurs sont partagés entre plusieurs Organizations : Tout utilisateur peut appartenir à plusieurs Organizations et devrait pouvoir utiliser la même identité pour passer d’une Organizations à l’autre.
En reprenant notre exemple Travel0 Adventure Management, supposons les utilisateurs suivants :
  • Jonno : Un guide employé directement par Rocky Mountain High Adventures et qui ne devrait pouvoir se connecter qu’à l’Organizations de 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 doit être membre de l’Organizations Rocky Mountain.
  • Hiroko : Une guide employée directement par Granite Outpost Rafting and Ziplines et qui ne devrait pouvoir se connecter qu’à l’Organizations de 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; Hiroko doit aussi être membre de l’Organizations Granite Outpost. Si vous utilisez l’IdP de Granite Outpost, la connexion d’entreprise doit également être activée pour l’Organizations.
  • 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 Organizations. Si nous voulons qu’Emilio puisse utiliser les mêmes identifiants pour les deux Organizations, ses identifiants devraient être stockés dans la connexion de base de données Travel0, et Emilio devrait être membre des Organizations Rocky Mountain et Granite Outpost. Sinon, Emilio devra configurer un jeu d’identifiants dans la connexion de base de données Travel0 pour Rocky Mountain High Adventures et être membre de l’Organizations Rocky Mountain High, puis configurer un autre jeu d’identifiants soit dans la connexion de base de données Travel0, soit dans la connexion d’entreprise de Granite Outpost, et être membre de l’Organizations Granite Outpost. Enfin, si vous utilisez l’IdP de Granite Outpost, la connexion d’entreprise configurée doit être activée pour l’Organizations 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 que Rocky Mountain a avec AdventureZ. AdventureZ et Rocky Mountain ont des systèmes d’évaluation pour leurs guides, et les évaluations de Sumana doivent suivre d’AdventureZ à Rocky Mountain et être combinées entre les Organizations. Soit les identifiants de Sumana devraient être stockés dans la connexion de base de données Travel0 et Sumana devrait être membre des Organizations Rocky Mountain et AdventureZ, soit, si AdventureZ souhaite 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 Organizations Rocky Mountain et AdventureZ. Si Sumana est aussi invitée à travailler comme pigiste pour Granite Outpost Rafting and Ziplines, ses identifiants pourraient être stockés dans la connexion de base de données Travel0 ou elle pourrait être ajoutée à l’IdP de Granite Outpost, et elle devrait être membre de l’Organizations Granite Outpost.
Une fois que vous aurez déterminé combien d’Organizations vous aurez et à quoi devrait ressembler votre modèle de connexion, vous pourrez configurer des connexions de base de données, sociales ou d’entreprise, créer des Organizations et configurer l’appartenance à une Organizations ou activer les connexions d’Organizations.

​
Modèle d’accès aux applications

Par défaut, les membres d’une organisation peuvent accéder à toute application pour laquelle Organizations est activé et une connexion active est configurée. Il s’agit du modèle d’accès implicite. Vous pouvez faire passer certaines organisations à un modèle d’accès explicite à l’aide de l’accès par application. Lorsqu’il est activé pour une organisation, les applications de première partie sans autorisation explicite sont bloquées. Les applications tierces sans autorisation explicite continuent de suivre la politique d’accès aux applications tierces de l’organisation. Les autres organisations de votre tenant ne sont pas touchées. Utilisez le modèle explicite lorsque vous devez :
  • Restreindre l’accès aux produits qu’une organisation cliente donnée a achetés.
  • Empêcher les membres d’accéder aux applications pour lesquelles leur organisation n’a pas été provisionnée.
  • Gérer les droits d’accès aux applications sans recourir à des Actions personnalisées ni à des solutions de contournement avec app_metadata.
Pour commencer, consultez Accorder l’accès d’une organisation à une application.

​
Rôles

Les membres des organisations peuvent se voir attribuer des rôles. Vous pouvez utiliser ces rôles pour définir le contrôle d’accès de votre application. Par exemple, si vous avez créé un tableau de bord pour vos utilisateurs à l’aide de notre API et de nos SDKs, vous pourriez attribuer un rôle d’administrateur à certains membres et leur permettre de gérer eux-mêmes leurs organisations à partir de votre tableau de bord.
La Management API doit être utilisée uniquement avec un client confidentiel. Son utilisation est assujettie aux limites de taux de l’Auth0 Management API.

​
Limitations

La fonctionnalité Organizations d’Auth0 présente les limitations suivantes :
  • Votre forfait 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 Organizations est activé ne sont pas compatibles avec les grants et protocoles suivants : Password, Device , (Auth0 comme IdP).
  • Ne prend pas en charge :
    • Les domaines personnalisés par organisation (par exemple, selon 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, alors Organizations 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 tenants Auth0.
    • L’intégration avec Delegated Administration Extension.
    • L’intégration avec Authorization Extension.
Les applications tierces sont prises en charge avec Organizations. Pour savoir comment activer une application tierce pour votre Organization, consultez Activer l’accès des applications tierces pour une Organization.

​
En savoir plus