Skip to main content
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 proposons des conseils d’ordre général sur la gestion du profil B2B, que nous vous recommandons de consulter en complément des indications fournies ici.
Avant de pouvoir gérer les rôles associés à un utilisateur, un compte d’utilisateur doit exister dans Auth0. Cela s’applique même si vous utilisez la capacité de rôle d’Auth0 Organizations associée à l’appartenance. Toutefois, les comptes d’utilisateur provisionnés au moyen du flux de travail 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 d’une organisation. Si vous préinscrivez un utilisateur au moyen d’un autre mécanisme, vous devez stocker les renseignements sur le rôle à l’extérieur d’Auth0 et y accéder ou les copier à l’aide 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 aux utilisateurs une forme de gestion en libre-service. De plus, ou en remplacement, vous pouvez offrir une gestion du profil en libre-service pour les attributs habituellement gérés par le (IdP).
Bonne pratiqueDans les scénarios liés aux organisations, les adresses courriel devraient toujours être vérifiées. Par conséquent, vous devriez offrir une fonctionnalité de vérification du courriel en libre-service lorsque l’adresse courriel d’un utilisateur ne peut pas être vérifiée autrement. Pour plus de détails, consultez Vérification du courriel.

​
Connexion de base de données

Auth0 vous permet de mettre en place la gestion du profil en libre-service au moyen de l’Auth0 . Si vous utilisez Auth0 Organizations pour offrir le provisionnement des utilisateurs sur invitation, vous devrez probablement restreindre les modifications apportées aux champs qui relèvent habituellement de votre tenant Auth0 en tant que fournisseur d’identité (IdP). Par exemple, vous voudrez restreindre les modifications à l’adresse courriel, car vous ne voudriez pas qu’un utilisateur utilise une adresse courriel autre que celle à laquelle son invitation a été envoyée. En restreignant les modifications au champ d’adresse courriel, vous éviterez que des courriels propres à l’entreprise soient envoyés à des adresses courriel personnelles saisies. Autrement, vous pourriez envisager d’offrir quelques fonctionnalités en libre-service aux utilisateurs qui s’authentifient au moyen d’une connexion de base de données dans Auth0. Vous pourriez vouloir permettre aux utilisateurs de :
  • modifier leur adresse 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 GDPR)
  • effectuer un changement de mot de passe, ce que nous recommandons généralement de mettre en œuvre au moyen de la réinitialisation du mot de passe et qui tirera habituellement parti de l’image de marque propre à l’organisation décrite dans Image de marque : page de réinitialisation du mot de passe.
Cette fonctionnalité en libre-service doit généralement être mise en œuvre et hébergée à l’extérieur d’Auth0, et elle doit être hautement sécurisée.

​
Connexion d’entreprise

Comme le fournisseur d’identité (IdP) en amont gère généralement les attributs du profil utilisateur qui relèvent de l’IdP, la gestion du profil peut être presque inexistante dans ce cas d’utilisation. Toutefois, si vous utilisez des attributs utilisateur propres à l’application, vous pourriez quand même vouloir offrir des fonctionnalités en libre-service. De plus, vous voudrez presque certainement offrir à une organisation un moyen de désapprovisionner des utilisateurs de votre tenant Auth0. Auth0 ne communique pas avec un IdP en amont, sauf lorsque la session d’Auth0 expire. Comme le délai avant l’expiration d’une session SSO sera probablement trop long dans la plupart des cas où un utilisateur est supprimé, un administrateur de l’organisation devra disposer d’un moyen de bloquer ou de supprimer un utilisateur de façon indépendante.

​
Connexion sociale

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 d’identité sociale plutôt qu’à une organisation en particulier.

​
Administration

Dans certaines situations, vous voudrez donner à vos clients l’accès nécessaire pour gérer les comptes d’utilisateur associés à leur organisation. C’est souvent le cas dans des scénarios de type centre d’assistance, où un agent peut mettre à jour les renseignements du profil au nom d’un utilisateur ou aider un utilisateur à débloquer son compte. Par défaut, Auth0 fournit le , qui sert à la gestion générale d’un tenant Auth0. Toutefois, vous ne voudriez pas donner à un client l’accès à l’Auth0 Dashboard de votre tenant Auth0, car il pourrait alors gérer tous les utilisateurs de toutes les organisations, ce qui ne serait pas souhaitable.
Bien que l’Auth0 Dashboard de votre tenant Auth0 puisse être utilisé pour gérer les 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 adaptée aux Organizations d’Auth0; toutefois, il ne peut pas être utilisé pour gérer l’appartenance ou l’invitation d’un utilisateur.
Si vous offrez déjà à vos clients des capacités de type centre 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 appartient un utilisateur. Si vous n’offrez pas déjà ce type de service d’assistance, vous devrez développer cette fonctionnalité si vous en avez besoin.