Découvrez la gestion du profil utilisateur pour les organisations dans les architectures multilocataires.
La gestion du profil dans les scénarios basés sur les organisations est généralement la même que dans les autres scénarios d’architecture. Dans nos scénarios d’architecture, nous fournissons des conseils généraux sur la gestion des profils B2B, que nous vous recommandons de consulter en parallèle avec ceux fournis ici.
Avant de pouvoir gérer les rôles associés à un utilisateur, un compte utilisateur doit exister dans Auth0. Cela s’applique même si vous utilisez la fonctionnalité de rôles d’Auth0 Organizations associée à l’appartenance. Toutefois, les comptes utilisateur provisionnés au moyen du processus d’invitation d’utilisateur peuvent se voir attribuer automatiquement un rôle dans le cadre du processus d’invitation. Pour en savoir plus, consultez Inviter des membres de l’organisation. Si vous préinscrivez un utilisateur au moyen d’un autre mécanisme, vous devez stocker les informations sur le Role à l’extérieur d’Auth0 et y accéder ou les copier au moyen de l’extensibilité (par exemple, dans le cadre d’une Rule) lors de la première authentification.
Votre application peut être associée à un ensemble précis d’attributs utilisateur (par exemple, des préférences utilisateur ou des renseignements d’identification que vous utilisez pour mieux servir le client) pour lesquels vous offrez une forme de gestion en libre-service aux utilisateurs. De plus, ou à la place, vous pouvez offrir une gestion en libre-service du profil pour des attributs généralement maintenus par le (IdP).
Bonne pratiqueDans les scénarios liés aux organisations, les adresses de courriel devraient toujours être vérifiées. Par conséquent, vous devriez offrir une fonctionnalité en libre-service de vérification du courriel dans les cas où l’adresse de courriel d’un utilisateur ne peut pas être vérifiée autrement. Pour en savoir plus, consultez Vérification du courriel.
Auth0 vous permet de mettre en œuvre la gestion de profil en libre-service au moyen de l’Auth0 . Si vous utilisez Auth0 Organizations pour offrir le provisionnement des utilisateurs par invitation, vous devrez probablement restreindre les modifications aux champs qui relèvent généralement de votre locataire Auth0 en tant que fournisseur d’identité (IdP). Par exemple, vous voudrez restreindre les modifications à l’adresse de courriel, car vous ne voudriez pas qu’un utilisateur utilise une adresse de courriel autre que celle à laquelle son invitation a été envoyée. Le fait de restreindre les modifications au champ de l’adresse de courriel empêcherait que des courriels propres à l’entreprise soient envoyés à des adresses de courriel personnelles saisies.Sinon, vous pourriez envisager d’offrir quelques options en libre-service aux utilisateurs qui s’authentifient au moyen d’une connexion de base de données dans Auth0. Vous pourriez permettre aux utilisateurs de :
modifier leur adresse de courriel
modifier les numéros de téléphone associés
modifier leur nom d’utilisateur
déprovisionner leurs comptes pour respecter les exigences réglementaires (comme le RGPD)
Comme le fournisseur d’identité (IdP) en amont gère généralement les attributs du profil utilisateur administrés par l’IdP, la gestion du profil est souvent quasi inexistante dans ce cas d’utilisation. Toutefois, si vous utilisez des attributs utilisateur propres à l’application, vous pourriez tout de même vouloir offrir une fonctionnalité en libre-service.De plus, vous voudrez presque certainement offrir à une organisation un moyen de déprovisionner des utilisateurs de votre locataire Auth0. Auth0 ne communique pas avec un IdP en amont, sauf lorsque la session Auth0 expire. Comme la durée de vie d’une session SSO sera probablement trop longue pour la plupart des scénarios où un utilisateur est supprimé, un administrateur d’organisation devra disposer d’un moyen de bloquer ou de supprimer un utilisateur de façon indépendante.
Dans le contexte des connexions sociales, la gestion du profil suit un modèle semblable à celui associé à une Connexion d’entreprise, mais l’IdP en amont est associé au fournisseur social plutôt qu’à une organisation en particulier.
Dans certaines situations, vous voudrez donner à vos clients accès à la gestion des comptes d’utilisateur associés à leur organisation. C’est souvent le cas dans des scénarios de type service d’assistance, où un agent peut mettre à jour les renseignements de profil au nom d’un utilisateur ou aider un utilisateur à débloquer un compte.Par défaut, Auth0 fournit le , qui sert à la gestion générale d’un locataire Auth0. Cependant, vous ne voudriez pas donner à un client l’accès à l’Auth0 Dashboard de votre locataire, car il pourrait alors gérer tous les utilisateurs de toutes les organisations, ce qui ne serait pas souhaitable.
Bien que l’Auth0 Dashboard du locataire puisse être utilisé pour gérer des comptes d’utilisateur, il n’offre pas d’isolation au niveau de l’organisation. Donner à un client l’accès à votre Auth0 Dashboard lui permet de modifier des utilisateurs dans toutes les organisations, ce qui n’est pas souhaitable. Le tableau de bord Auth0 Delegated Admin peut être configuré pour offrir une administration des comptes d’utilisateur qui tient compte des organisations Auth0; toutefois, il ne peut pas être utilisé pour gérer l’appartenance ou l’invitation des utilisateurs.
Si vous offrez déjà à vos clients des fonctionnalités de type service d’assistance, vous pouvez utiliser l’Auth0 Management API pour gérer les comptes d’utilisateur dans Auth0. Par exemple, la Management API peut être utilisée pour récupérer les membres d’une organisation et les organisations auxquelles un utilisateur appartient. Si vous n’offrez pas déjà ce type de service d’assistance, vous devrez développer cette fonctionnalité si vous en avez besoin.