Fonctionnalités de provisionnement des utilisateurs et considérations à prendre en compte pour votre implémentation B2B IAM.
Il est important de déterminer tôt comment les utilisateurs s’inscriront, 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 plusieurs éléments à prendre en compte dans la conception du flux de travail.
Bien qu’Auth0 prenne en charge de nombreux flux de travail, les flux de travail Web utilisant Universal Login pour l’inscription sont considérés comme une pratique exemplaire, tant dans l’industrie que chez Auth0, car ils offrent des fonctionnalités optimales et le meilleur niveau de sécurité.
Auth0 prend en charge l’inscription des utilisateurs au moyen de différents fournisseurs d’identité. Pendant l’inscription, Auth0 provisionne le profil utilisateur afin qu’il contienne les renseignements du compte de l’utilisateur. Plusieurs éléments doivent être pris en compte en ce qui concerne les fonctionnalités et le flux de travail :
Un utilisateur est-il ajouté au domaine de votre entreprise ou appartient-il, ou reste-t-il, dans le domaine de son organisation ?
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 magasin d’identités ?
Pouvez-vous utiliser votre propre magasin d’identités existant avec Auth0 ?
Comment migrez-vous les identités des utilisateurs de votre magasin d’identités 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 appartiennent les utilisateurs. Selon la réponse à cette question, vous pouvez adopter différentes approches pour provisionner ces utilisateurs. Consultez Provisioning organization users pour en savoir plus. Une fois que vous avez déterminé comment les organisations seront représentées dans votre système, vous devrez réfléchir à la façon de provisionner l’organisation elle-même. Consultez Provisioning organizations pour en savoir plus.Auth0 fournit un stockage d’identités prêt à l’emploi qui peut être utilisé pour stocker les identifiants des utilisateurs de façon sûre et sécurisée. Consultez Self Sign Up pour en savoir plus. Si vous disposez déjà d’un magasin d’identités existant et que vous souhaitez en déléguer la gestion, les fonctionnalités de User Migration vous offrent plusieurs options à cet effet.Sinon, si vous devez conserver votre magasin d’identités existant — peut-être 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é proxy de magasin d’identités. Permettre à vos clients d’utiliser leur propre système d’identité est également 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é Social Sign Up pour le permettre.
Les tâches à effectuer lors du provisionnement d’une organisation dépendent de la façon dont les organisations sont représentées dans votre système. Il peut être utile de prendre un pas de recul et de réfléchir à la manière dont les utilisateurs de ces organisations interagiront avec vos applications. Consultez Multiple Organization Architecture pour déterminer comment configurer les organisations pour votre système IAM.Lors du provisionnement des organisations, vous devez tenir compte des éléments suivants :
Vous devrez ajouter l’organisation à la configuration de votre application et/ou à votre base de données
Vous devrez apporter des modifications à votre configuration Auth0. Cela comprendra tout ou partie des actions suivantes :
Dans de rares cas : créer un locataire distinct pour l’organisation
Créer une nouvelle Organisation dans votre locataire Auth0
Ajouter une nouvelle connexion de base de données pour cette Organisation (si vous isolez les utilisateurs par organisation)
Activer la connexion de base de données partagée existante pour cette Organisation (si les utilisateurs sont partagés)
Ajouter une connexion d’entreprise pour cette Organisation et l’activer pour l’Organisation
Cela impliquera de travailler avec l’organisation pour soit mettre à jour sa configuration existante, soit ajouter une configuration pour votre locataire Auth0 si elle n’est pas une organisation héritée.
Provisionner un administrateur pour l’organisation
Vous pouvez également envisager de créer un portail d’inscription autonome pour vos Organisations. Cela permet à vos clients de créer eux-mêmes leur organisation. Cela peut faire partie du 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 client. Plusieurs tâches doivent être effectuées à la fois dans votre propre système et dans votre locataire Auth0. Ce portail devra vraisemblablement se trouver dans votre propre système afin d’avoir accès à vos sources de données et à votre configuration. Toutefois, Auth0 fournit l’Auth0 Management API afin que vous puissiez répercuter les changements dans votre locataire 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. Le choix dépend en grande partie du délai de déploiement d’une nouvelle organisation que vous êtes prêt à accepter.
Mises à jour en direct de votre locataire Auth0 : Si vous voulez pouvoir créer de nouvelles organisations en temps réel, vous voudrez probablement apporter les modifications directement à votre locataire Auth0 au moyen de l’Auth0 . Cela permet d’appliquer les changements en temps réel et de rendre l’ajout d’une nouvelle organisation effectif immédiatement. En particulier, si vous offrez l’inscription en libre-service pour les organisations, vous voudrez peut-être privilégier cette approche.
Les mises à jour en direct comportent toutefois certains points à prendre en compte. Certaines opérations doivent être effectuées en série pour éviter les problèmes. L’activation d’applications sur une connexion 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 en entier avec la 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 utilisez la Deploy CLI (ou une CLI personnalisée) dans le cadre de votre pipeline CI/CD, vous préférerez peut-être envoyer directement vos changements dans votre dépôt, puis déclencher un nouveau déploiement. Cela peut prendre un peu plus de temps, mais cette approche 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 ancien magasin d’identités et offrir une solution de remplacement sécurisée hébergée par Auth0. Ces deux possibilités sont prises en charge au moyen des connexions de base de données Auth0. Si vous choisissez d’utiliser Auth0 pour remplacer votre ancien magasin d’identités, vous pouvez migrer les utilisateurs soit en une seule fois avec une migration en masse, soit progressivement avec la 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 masse pour les utilisateurs restants. Consultez Scénarios de migration des utilisateurs pour en savoir plus.
La migration automatique est à privilégier, car elle permet de migrer les utilisateurs individuellement et, dans presque tous les cas, de conserver leurs mots de passe existants. Pour la migration en masse, nous recommandons d’utiliser la Management API plutôt que l’extension User Import/Export dans tous les cas sauf les plus simples, car la Management API offre une plus grande souplesse et un meilleur contrôle.Avec la migration en masse, les utilisateurs doivent généralement réinitialiser leur mot de passe une fois la migration terminée, sauf si les mots de passe sont stockés sous forme hachée dans votre ancien magasin d’identités au moyen de l’un des algorithmes pris en charge. Dans ce cas, vous pourrez peut-être utiliser la migration en masse et préserver les mots de passe des utilisateurs dans le cadre du processus, selon l’algorithme et le nombre de tours de salage utilisés. Consultez Exemples de schéma de base de données pour l’importation en masse pour en savoir plus.
L’importation de mots de passe hachés repose sur l’utilisation, par le magasin d’identités source, d’implémentations idiomatiques de l’un des algorithmes suivants : argon2, bcrypt, hmac, ldap, md4, md5, sha1, sha256, sha512, pbkdf2 et scrypt.
Les appels à la Management API sont assujettis à la stratégie de limitation du débit d’Auth0. Vous devez en tenir compte et, à cette fin, 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 connexions de base de données Auth0 peuvent aussi être configurées comme proxy d’un magasin d’identités existant (hérité). Si vous devez conserver des identités utilisateur définies dans votre propre magasin d’identités hérité — par exemple, si vous avez une ou plusieurs applications essentielles à l’entreprise que vous ne pouvez pas migrer vers Auth0, mais qui doivent quand même avoir accès à ces identités — vous pouvez facilement les intégrer à Auth0. Consultez Authentifier des utilisateurs à l’aide de votre base de données pour en savoir plus.
Provisionnement des utilisateurs d’une organisation
Une organisation devrait correspondre directement à l’un de vos clients ou partenaires commerciaux. Chaque client ou partenaire avec lequel vous travaillez a des utilisateurs qui se connecteront. Nous appelons ces utilisateurs finaux 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 qu’un 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 plusieurs organisations : Dans ce cas, les utilisateurs créent soit des identifiants auprès de votre entreprise, soit ils peuvent accéder aux instances de votre application d’autres organisations à l’aide des identifiants de leur propre organisation. Autrement dit, un même utilisateur peut être autorisé à accéder à l’instance de l’application de plusieurs organisations. L’utilisateur comprendra qu’il peut utiliser les mêmes identifiants pour accéder aux deux instances de l’application. Par exemple, certains médecins travaillent sous contrat avec plusieurs cliniques et peuvent devoir ouvrir une session dans chacune d’elles avec les mêmes identifiants. Pour en savoir plus, consultez Provisionnement des utilisateurs partagés entre plusieurs organisations.
Provisionnement des utilisateurs isolés au sein de l’organisation
Le fait d’isoler les utilisateurs au sein de l’organisation peut créer une séparation claire 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. Chacune des organisations aura son propre IdP à cette fin. Cet IdP prendra l’une des trois formes suivantes :
Votre locataire Auth0 est l’IdP : une connexion de base de données dans votre locataire principal, dédiée à cette organisation.
Les organisations fournissent leur propre IdP : vous configurez une connexion d’entreprise pour elles.
Organisations ayant plus d’un IdP : vous activez plus d’une connexion d’entreprise, plus d’une connexion sociale, et vous pouvez aussi avoir une seule connexion de base de données. Lorsque l’utilisateur choisit son organisation et tente de se connecter, il peut choisir parmi toutes les connexions activées pour cette organisation.
Nous recommandons d’utiliser Auth0 comme IdP pour commencer, car il est simple de mettre en œuvre un processus d’invitation d’utilisateurs. Par rapport à d’autres processus d’invitation, la seule particularité ici est que la personne qui crée l’utilisateur devra soit sélectionner l’organisation à l’avance, 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).
Provisionnement des utilisateurs partagés entre les organisations
Lorsque vous partagez des utilisateurs entre plusieurs organisations, vous devez disposer d’un moyen de contrôler 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 peuvent accéder en les ajoutant comme membres de l’organisation. Par conséquent, le provisionnement commence souvent par un flux d’invitation d’utilisateur pour une connexion de base de données unique, puis les utilisateurs sont ajoutés à l’organisation à l’aide de la Management API. Vous pouvez ensuite utiliser la Management API pour récupérer les organisations dont l’utilisateur est membre si vous devez lui permettre de passer d’une organisation à l’autre.
Auth0 ne communiquera pas avec l’IdP en amont s’il existe une session active avec Auth0, à moins de le forcer avec prompt=login. Si l’une des organisations de vos clients ne peut pas gérer la déconnexion de ces utilisateurs, ils pourraient quand même conserver l’accès après leur retrait. Selon l’IdP, si Auth0 obtient un jeton pour son API, vous pouvez demander des renseignements sur l’utilisateur à l’IdP dans une Rule afin de vérifier périodiquement 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 le retrait d’utilisateurs dans votre système, soit au moyen d’un appel d’API, soit par une interface utilisateur.
Dans la plupart des scénarios B2B, seules certaines personnes sont autorisées à accéder à l’application. Il est donc souvent plus simple de demander à un administrateur de créer les comptes d’utilisateur plutôt que de laisser les utilisateurs s’inscrire, puis de faire approuver leur inscription par un administrateur. Le provisionnement peut aussi souvent être automatisé lorsque des utilisateurs sont ajoutés à un système centralisé.Trois types d’intervenants peuvent 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 exister un autre système chargé de créer les utilisateurs, et ce système peut ensuite créer un utilisateur dans Auth0. Quelle que soit l’, la méthode peut être similaire. 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é Organisations. Si vous n’utilisez pas la fonctionnalité Organisations pour mettre en place les 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 et un mot de passe temporaire aléatoire. Le mot de passe généré ne doit ê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 à l’utilisateur un courriel contenant un lien pour réinitialiser son mot de passe ; vous pouvez même modifier le gabarit de courriel dans Auth0 pour indiquer qu’il s’agit aussi d’un flux 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 d’autre que l’utilisateur lui-même ne connaît jamais son mot de passe. Si vous mettez en place un flux d’invitation, faites générer un mot de passe aléatoire par votre système backend, puis supprimez-le, et demandez à votre utilisateur de réinitialiser son mot de passe avant même de se connecter. Ne créez pas de mot de passe temporaire à lui remettre pour une première connexion.
L’inscription d’entreprise est synonyme de connexion par connexion d’entreprise — il n’y a pas vraiment de distinction ici, puisque la création du profil de l’utilisateur se fait automatiquement lors de la première connexion d’entreprise.
Un avantage important du fait de permettre à vos clients d’utiliser leur propre IdP est qu’ils peuvent gérer leurs utilisateurs et attribuer les rôles et les accès dans la configuration de leur propre IdP, plutôt que de vous obliger à développer ces fonctions d’administration pour eux. Définir le mappage pour ces clients facilitera grandement les choses.
Si le mappage ne suffit pas et que vous devez ajouter 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 récupérer les informations initiales à partir d’une autre source, ou obliger les utilisateurs à se connecter une première fois avant de pouvoir ajouter les métadonnées.
Nous mettons à votre disposition un guide de planification au format PDF, que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons.Guide de planification du projet B2B IAM
De nombreuses plateformes B2B mettent en œuvre une certaine forme d’isolation et/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 multi-organisation
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme