Fonctionnalité de provisionnement des utilisateurs et points à considérer pour votre mise en œuvre B2B IAM.
Déterminer tôt comment les utilisateurs s’inscriront est important, car les décisions prises à cette étape influenceront bon nombre de celles que vous devrez prendre par la suite. Nous avons constaté qu’il existe un ensemble de modèles courants pour l’ajout d’utilisateurs à votre système, ainsi que certains points à considérer dans la conception du flux de travail.
Bien qu’Auth0 prenne en charge de nombreux flux de travail, les flux de travail Web qui utilisent Universal Login pour l’inscription sont considérés comme une bonne pratique, tant dans l’industrie que chez Auth0, puisqu’ils offrent des fonctionnalités optimales et le meilleur niveau de sécurité.
Auth0 prend en charge l’inscription des utilisateurs au moyen de plusieurs fournisseurs d’identité. Pendant l’inscription, Auth0 provisionne le profil utilisateur afin qu’il contienne les renseignements du compte de l’utilisateur. Voici plusieurs éléments à considérer sur le plan des fonctionnalités et du flux de travail :
Un utilisateur est-il ajouté au domaine de votre entreprise, ou appartient-il au domaine de son organisation, ou y demeure-t-il ?
Si l’utilisateur reste dans son propre domaine, appartient-il à une seule organisation ou peut-il appartenir à plusieurs organisations ?
Comment provisionnez-vous l’organisation elle-même dans votre système ?
Devriez-vous utiliser Auth0 comme référentiel d’identité ?
Pouvez-vous utiliser votre propre stockage d’identités hérité avec Auth0 ?
Comment migrez-vous les identités des utilisateurs de votre référentiel d’identité vers Auth0 ?
Vos utilisateurs peuvent-ils s’inscrire en utilisant le de leur organisation ?
Vos utilisateurs peuvent-ils être invités ou s’inscrire eux-mêmes ?
L’une des premières décisions à prendre lorsque vous offrez vos services à d’autres entreprises consiste à déterminer à quel domaine les utilisateurs appartiennent. Selon la réponse à cette question, différentes approches s’offrent à vous pour provisionner ces utilisateurs. Consultez Provisionnement des utilisateurs de l’organisation pour en savoir plus. Une fois que vous saurez comment vous voulez que les organisations soient représentées dans votre système, vous devrez aussi réfléchir à la façon dont vous allez provisionner l’organisation elle-même. Consultez Provisionnement des organisations pour en savoir plus.Auth0 fournit un stockage d’identité prêt à l’emploi qui peut servir à stocker les identifiants des utilisateurs de façon sûre et sécuritaire. Consultez Auto-inscription pour en savoir plus. Si vous disposez déjà d’un stockage d’identités hérité et que vous souhaitez en déléguer la gestion, les fonctionnalités de Migration des utilisateurs vous offrent plusieurs options à cet effet.Autrement, si vous devez conserver votre stockage d’identités hérité — par exemple parce que vous avez des applications que vous n’êtes pas prêt à migrer ou qui ne peuvent pas l’être — vous pouvez utiliser la fonctionnalité de proxy de référentiel d’identité. Permettre à vos clients d’utiliser « leur propre identité » est aussi une option intéressante et, même si nous constatons que nos clients ne le font généralement pas au départ, vous pouvez utiliser la fonctionnalité d’inscription sociale pour l’offrir.
Ce que vous devez faire pour provisionner une organisation dépend de la façon dont les organisations sont représentées dans votre système. Il peut être utile de prendre un peu de recul et de réfléchir à la façon dont les utilisateurs de ces organisations interagiront avec vos applications. Consultez Multiple Organization Architecture pour déterminer comment configurer les organisations dans votre système IAM.Lorsque vous provisionnez des organisations, vous devez tenir compte des éléments suivants :
Vous devrez ajouter l’organisation à la configuration de votre propre application et/ou à votre base de données
Vous devrez apporter des modifications à votre configuration Auth0. Cela peut comprendre tout ou partie des éléments suivants :
Dans de rares cas : créer un tenant distinct pour l’organisation
Créer une nouvelle organisation dans votre tenant Auth0
Ajouter une nouvelle Database Connection pour cette organisation (si vous isolez les utilisateurs par organisation)
Activer la Database Connection partagée existante pour cette organisation (si vous partagez les utilisateurs)
Ajouter une Enterprise Connection pour cette organisation et l’activer pour l’organisation
Cela comprend la collaboration avec l’organisation pour soit mettre à jour sa configuration existante, soit ajouter une configuration pour votre tenant Auth0 si ce n’est pas une organisation Legacy.
Provisionner un administrateur pour l’organisation
Vous pourriez également vouloir créer un portail de Self-Signup pour vos organisations. Cela permet à vos clients de créer eux-mêmes leur organisation. Cela peut faire partie de l’portail d’administration des organisations.
Un portail d’administration des organisations permet à vos administrateurs de créer, de modifier et de supprimer des organisations. Ces administrateurs peuvent être des employés de votre entreprise ou des administrateurs côté client. Plusieurs tâches doivent être effectuées à la fois dans votre propre système et dans votre tenant Auth0. Ce portail devra probablement se trouver dans votre propre système afin d’avoir accès à vos magasins de données et à votre configuration. Cependant, Auth0 fournit l’Auth0 Management API afin que vous puissiez répercuter les changements dans votre tenant Auth0 en même temps que vous les apportez dans votre propre système.Il existe deux grandes approches pour créer une nouvelle organisation. Celle que vous choisissez dépend en grande partie du délai de déploiement d’une nouvelle organisation que vous êtes prêt à tolérer.
Mises à jour en direct de votre tenant Auth0 : Si vous voulez pouvoir créer de nouvelles organisations en temps réel, vous voudrez probablement apporter les modifications directement à votre tenant Auth0 à l’aide de l’Auth0 . Ainsi, les changements sont appliqués en temps réel et l’ajout d’une nouvelle organisation prend effet immédiatement. Cette approche peut être particulièrement pertinente si vous offrez le Self-Signup pour les organisations.
Les mises à jour en direct comportent tout de même certains éléments à prendre en compte. Certaines opérations doivent être effectuées en série afin d’éviter des problèmes. L’activation de clients sur une connection et l’ajout d’URL de rappel à une Application en sont deux exemples. Toute opération dans la Management API où vous devez récupérer une liste complète, puis la soumettre de nouveau au complet avec une nouvelle valeur ajoutée, doit être effectuée en série afin d’éviter que deux opérations parallèles n’écrasent l’une des valeurs.
Modifier le dépôt et redéployer : Si vous tirez parti du Deploy CLI (ou d’un CLI personnalisé) dans le cadre de votre pipeline CI/CD, vous pourriez préférer pousser vos changements directement vers votre dépôt, puis lancer un nouveau déploiement. Cela peut prendre un peu plus de temps, mais offre des avantages liés à l’historique des versions et à la possibilité d’annuler un changement en redéployant la version précédente. Vous pourriez aussi vouloir avoir un dépôt distinct uniquement pour les éléments dont les organisations ont besoin, afin de ne pas avoir à redéployer d’autres composants communs et de réduire le risque d’erreur.
En plus d’héberger le profil utilisateur, Auth0 peut aussi servir de proxy pour votre stockage d’identités hérité et offrir une solution de remplacement sécurisée hébergée par Auth0. Ces deux capacités sont prises en charge au moyen des Database Connections d’Auth0. Si vous décidez d’utiliser Auth0 pour remplacer votre stockage d’identités hérité, vous pouvez migrer les utilisateurs soit en une seule fois au moyen d’une migration en bloc, soit progressivement avec une migration automatique.
Les clients optent souvent pour une approche de migration des utilisateurs en deux étapes : ils utilisent d’abord la migration automatique pour migrer le plus d’utilisateurs possible, puis la migration en bloc pour ceux qui restent. Consultez User Migration Scenarios pour en savoir plus.
La migration automatique est à privilégier, car elle permet de migrer les utilisateurs individuellement tout en leur permettant de conserver leur mot de passe existant dans presque tous les cas. Pour la migration en bloc, nous recommandons d’utiliser la Management API plutôt que l’extension User Import/Export dans tous les cas sauf les plus simples, puisque la Management API offre davantage de souplesse et de contrôle.Avec la migration en bloc, les utilisateurs doivent généralement réinitialiser leur mot de passe une fois la migration terminée à moins que les mots de passe ne soient stockés sous forme hachée dans votre stockage d’identités hérité au moyen de l’un des algorithmes pris en charge. Dans ce cas, il se peut que vous puissiez utiliser la migration en bloc et préserver les mots de passe des utilisateurs dans le cadre du processus, selon l’algorithme utilisé et le nombre d’itérations de salage. Consultez Bulk Import Database Schema Examples pour en savoir plus.
L’importation de mots de passe hachés dépend de l’utilisation, par le référentiel d’identité source, de mises en œuvre idiomatiques de l’un des algorithmes suivants : argon2, bcrypt, hmac, ldap, md4, md5, sha1, sha256, sha512, pbkdf2 et scrypt.
Les requêtes à la Management API sont assujetties à la politique de limitation du débit d’Auth0. Vous devez en tenir compte. Pour vous aider, Auth0 recommande généralement d’utiliser le SDK Auth0 approprié à votre environnement de développement plutôt que d’appeler directement nos API.
Les types de connexion Database d’Auth0 peuvent aussi être configurés pour servir de proxy vers un référentiel d’identité existant (ancien). Si vous devez conserver les identités d’utilisateurs définies dans votre propre référentiel existant — par exemple, si vous avez une ou plusieurs applications essentielles à l’entreprise que vous ne pouvez pas migrer vers Auth0, mais qui ont quand même besoin d’accéder à ces identités — vous pouvez facilement les intégrer à Auth0. Consultez Authentifier les utilisateurs à l’aide de votre base de données pour en savoir plus.
Provisionnement des utilisateurs de l’organisation
Une organisation devrait correspondre directement à l’un de vos clients ou partenaires d’affaires. Chaque entreprise ou partenaire avec qui vous travaillez a des utilisateurs qui se connecteront. Nous appelons ces utilisateurs finals des « utilisateurs de l’organisation ». Il existe deux façons de stocker les utilisateurs de votre organisation :
Isolés au sein de l’organisation : Chaque utilisateur appartient à une seule organisation. Il ne serait pas logique que cet utilisateur fasse partie de plus d’une organisation et, même si c’était le cas, il serait logique qu’il ait une « identité » distincte pour cette autre organisation. Par exemple, un employé du commerce de détail qui travaille à temps partiel dans deux magasins différents a deux ouvertures de session distinctes, une pour chacun de ces magasins, même si les deux magasins utilisent l’application SaaS. Pour en savoir plus, consultez Provisionnement des utilisateurs isolés au sein de l’organisation.
Partagés entre les organisations : Dans ce cas, les utilisateurs créent soit des identifiants dans votre entreprise, soit peuvent accéder aux instances de votre application d’autres organisations à l’aide des identifiants de leur propre organisation. En termes simples, cela signifie qu’un même utilisateur peut être autorisé à accéder à l’instance de l’application de plus d’une organisation. Un utilisateur comprendra qu’il peut utiliser les mêmes identifiants pour accéder aux deux instances d’une application. Par exemple, certains médecins travaillent avec plusieurs cliniques et peuvent avoir besoin d’accéder à chacune d’elles avec les mêmes identifiants. Pour en savoir plus, consultez Provisionnement des utilisateurs partagés entre les organisations.
Provisionnement d’utilisateurs isolés dans l’organisation
Isoler les utilisateurs dans leur organisation peut créer une séparation claire et nette entre les organisations. Si aucun utilisateur n’a besoin d’accéder à plus d’une organisation (ou si vous préférez les obliger à créer plusieurs comptes), cette approche est intéressante.Vous devez provisionner ces utilisateurs au niveau de l’IdP. Chaque organisation aura son propre IdP pour ce faire. Cet IdP prendra l’une des trois formes suivantes :
Votre tenant Auth0 est l’IdP : une Database Connection dans votre tenant principal, dédiée à cette organisation.
Les organisations apportent leur propre IdP : vous configurez une Enterprise Connection pour elles.
Organisations ayant plus d’un IdP : vous activez plusieurs Enterprise Connections et Social Connections, et vous pouvez aussi avoir une seule Database Connection. Lorsque l’utilisateur choisit son organisation et tente de se connecter, il peut choisir parmi toutes les connections activées pour cette organisation.
Nous vous recommandons d’utiliser Auth0 comme IdP pour commencer, car il est simple de mettre en place un workflow User invite. Comparativement aux autres processus d’invitation, la seule particularité est que la personne qui crée l’utilisateur devra soit sélectionner l’organisation au préalable, soit le système imposera que l’organisation corresponde à celle de l’utilisateur qui envoie l’invitation (dans les cas où un administrateur d’organisation appartient uniquement à cette organisation).
Si vous pouvez utiliser la fonctionnalité Organizations, cela simplifiera grandement votre système de connexion et le rendra plus facile à maintenir et à faire évoluer à l’avenir. Consultez Architecture à organisations multiples pour une explication plus détaillée.
Provisionnement des utilisateurs partagés entre des organisations
Lorsque vous partagez des utilisateurs entre des organisations, vous devez disposer d’un moyen d’autoriser l’accès. Comme vous ne saurez pas à quelle organisation un utilisateur peut appartenir au moment de l’authentification, nous recommandons généralement de stocker vos utilisateurs dans un seul domaine, puis de déterminer à quelles organisations ils ont accès en les ajoutant en tant que membres de l’organisation. Pour cette raison, le provisionnement se fait souvent en commençant par un workflow User invite pour l’unique connexion de base de données, puis en les ajoutant à l’organisation à l’aide de la Management API. Vous pouvez ensuite utiliser la Management API pour récupérer les organisations auxquelles l’utilisateur appartient si vous devez lui permettre de passer d’une organisation à une autre.
Auth0 ne communiquera pas avec l’IdP en amont s’il existe une session active avec Auth0, sauf si vous le forcez avec prompt=login. Si l’une des organisations de vos clients ne peut pas gérer le logout de ces utilisateurs, ils pourraient quand même avoir accès après leur mise hors service. Selon l’IdP, si Auth0 obtient un token pour son API, vous pouvez demander des renseignements sur l’utilisateur à l’IdP dans une rule afin de vérifier si cet utilisateur devrait toujours avoir accès ou non. Si vous n’avez pas cette capacité, vous devrez fournir aux organisations de vos clients un moyen de déclencher le blocage ou la mise hors service des utilisateurs dans votre système, soit au moyen d’un appel d’API, soit par une UI.
Dans la plupart des scénarios B2B, seules certaines personnes sont autorisées à accéder à l’application. Il est donc souvent plus simple qu’un administrateur crée des comptes d’utilisateur, plutôt que de laisser les utilisateurs s’inscrire puis faire approuver leur accès par un administrateur. Ce provisionnement peut aussi souvent se faire de façon automatisée lorsque des utilisateurs sont ajoutés à un système centralisé.Il existe trois types d’acteurs qui pourraient inviter des utilisateurs :
Un administrateur de votre entreprise peut créer les utilisateurs pour chaque organisation.
Un administrateur de chaque organisation peut être chargé de créer les utilisateurs.
Il peut aussi exister un autre système responsable de la création des utilisateurs, qui créera alors un utilisateur dans Auth0. Peu importe l’, la technique peut être semblable. Le reste consiste à utiliser le bon modèle d’autorisation pour l’application.
L’approche recommandée pour l’invitation d’utilisateurs consiste à utiliser la fonctionnalité Organizations. Si vous n’utilisez pas la fonctionnalité Organizations pour mettre en œuvre des invitations d’utilisateurs et que vous créez votre propre solution, il est important de créer chaque utilisateur avec le paramètre user.email_verified défini à false ainsi qu’un mot de passe temporaire aléatoire. Le mot de passe généré ne devrait être connu que d’Auth0 et ne doit pas être stocké dans un système externe ni transmis à l’utilisateur ! Ensuite, utilisez la Management API pour envoyer un courriel à l’utilisateur contenant un lien lui permettant de réinitialiser son mot de passe; vous pouvez même modifier le modèle de courriel dans Auth0 pour indiquer qu’il s’agit d’un processus d’inscription sur invitation. Cela garantit que l’adresse courriel de l’utilisateur appartient bien à l’utilisateur en cours de création et que la seule personne qui connaît le mot de passe est l’utilisateur lui-même.
L’un des principes fondamentaux d’OIDC est que personne, sauf l’utilisateur lui-même, ne connaît jamais son mot de passe. Si vous mettez en place un flux d’invitation, demandez à votre système backend de générer un mot de passe aléatoire, puis de le supprimer, et demandez ensuite à l’utilisateur de réinitialiser son mot de passe avant même de se connecter. Ne créez pas de mot de passe temporaire pour le lui remettre afin qu’il se connecte une première fois.
L’inscription d’entreprise est synonyme de connexion par connexion d’entreprise — il n’y a pas vraiment de distinction à faire ici, puisque la création du profil de l’utilisateur se fait automatiquement lors de la première connexion d’entreprise.
L’un des grands avantages de permettre à vos clients d’utiliser leur propre IdP, c’est qu’ils peuvent gérer leurs utilisateurs et attribuer les rôles et les accès dans la configuration de leur propre IdP, au lieu de vous obliger à créer cette administration pour eux. Établir le mappage pour ces clients simplifiera grandement les choses.
Si le mappage ne suffit pas et que vous devez stocker des métadonnées dans votre système, gardez à l’esprit qu’Auth0 ne créera pas l’utilisateur tant qu’il ne se sera pas connecté au système une première fois. Vous devrez donc utiliser l’extensibilité des règles pour aller chercher les informations initiales ailleurs, ou obliger les utilisateurs à se connecter une première fois avant de pouvoir ajouter les métadonnées.
Nous fournissons un guide de planification en PDF que vous pouvez télécharger et consulter pour plus de détails sur nos stratégies recommandées.Guide de planification de projet B2B IAM
Architecture à organisations multiples (multitenance)
De nombreuses plateformes B2B mettent en place une certaine forme d’isolation ou d’image de marque pour l’organisation de leurs clients, ce qui peut complexifier tout système de gestion des identités et des accès (IAM). Si c’est votre cas, nous vous recommandons de prendre le temps de consulter nos conseils et nos pratiques exemplaires pour ce type d’environnement.Architecture à organisations multiples
Assistant
Responses are generated using AI and may contain mistakes.
