Meilleure pratique
Bien qu’Auth0 prenne en charge de nombreux flux de travail, les flux de travail basés sur le web utilisant Auth0 Connexion universelle pour l’inscription sont considérés à la fois comme la meilleure pratique de l’industrie et d’Auth0, car ils garantissent une fonctionnalité optimale et une sécurité renforcée. Auth0 permet l’inscription des utilisateurs via divers fournisseurs d’identité. Lors de l’inscription, Auth0 provisionne le profil utilisateur en y intégrant les informations de compte associées. Plusieurs points clés sont à examiner lors de la conception des fonctionnalités et des flux de travail :- L’utilisateur est-il intégré au domaine de votre entreprise ou reste-t-il dans le domaine de son organisation d’origine?
- Si l’utilisateur reste dans son propre domaine, est-il associé à une seule organisation ou peut-il être lié à plusieurs organisations simultanément?
- Comment gérez-vous le provisionnement de 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 (ancien) avec Auth0?
- Comment migrer les identités des utilisateurs de votre magasin d’identités vers Auth0?
- Vos utilisateurs peuvent-ils s’inscrire en utilisant le fournisseur d’identité de leur organisation?
- Vos utilisateurs peuvent-ils être invités ou s’inscrire eux-mêmes?
Provisionnement des organisations
Ce que vous devez faire lors du provisionnement d’une organization dépend de la manière dont les organizations sont représentées dans votre système. Cela peut prendre un certain temps pour prendre du recul et réfléchir à la manière dont les utilisateurs de ces organisations interagiront avec vos applications. Veuillez consulter Architecture d’organisations multiples pour déterminer comment configurer les Organizations pour votre système IAM. Lors du provisionnement d’organisations, il est essentiel de prendre en compte les éléments suivants :- Vous devrez ajouter l’organisation à la configuration de votre application et/ou à votre base de données interne.
-
Plusieurs modifications seront nécessaires dans votre configuration Auth0, parmi lesquelles :
- Dans des cas exceptionnels : créer un locataire unique pour l’organisation
- Créer une nouvelle organisation dans votre locataire Auth0
- Si vous isolez les utilisateurs par organisation, vous devrez créer une nouvelle connexion de base de données pour cette organisation.
- Si vous partagez les utilisateurs entre plusieurs organisations, activez simplement la connexion de base de données partagée existante.
-
Ajoutez une connexion d’entreprise pour cette organisation et activez-la sur l’organisation
- Cela inclura la collaboration avec l’organisation pour mettre à jour sa configuration existante ou ajouter une configuration pour votre locataire Auth0 s’il ne s’agit pas d’une ancienne organisation.
- Provisionner un administrateur pour l’organisation
- Pour éviter les erreurs, il pourrait être judicieux de créer un portail d’administration des organisations, afin de simplifier le processus de provisionnement des nouvelles organisations.
- Il pourrait également être utile de mettre en place un portail d’auto-inscription pour vos organisations. Cela permet à vos clients de créer eux-mêmes l’organisation. Cela peut faire partie du portail d’administration de l’organisation.
Portail d’administration de l’organisation
Un portail d’administration d’organisation est un portail qui permet à vos administrateurs de créer, de modifier et de supprimer des organisations. Ces administrateurs peuvent être soit des employés de votre entreprise, soit des administrateurs clients. Plusieurs actions doivent être réalisées à la fois dans votre système interne et dans votre locataire Auth0. Ce portail devra probablement exister dans votre propre système afin d’avoir accès à vos magasins de données et à votre configuration. Cependant, Auth0 fournit la Auth0 Management API afin que vous puissiez intégrer les modifications à votre locataire Auth0 en même temps que vous créez les modifications dans votre propre système. Il existe deux principales approches qui peuvent être adoptées pour créer une nouvelle organisation. Le choix de l’une ou l’autre dépend fortement de votre tolérance concernant le temps nécessaire pour mettre en place cette nouvelle organisation.- Mises à jour en direct de votre locataire Auth0 : Si vous souhaitez créer de nouvelles organisations en temps réel, il serait probablement judicieux d’apporter les modifications directement à votre locataire Auth0 en utilisant . Cela permet des changements en temps réel et que l’ajout d’une nouvelle organisation prenne effet immédiatement. Cette méthode est tout particulièrement adaptée si vous offrez la possibilité aux organisations de s’inscrire de manière autonome.
Les mises à jour en direct sont assorties de certains éléments à prendre en compte. Certaines opérations doivent être effectuées en série pour éviter tout problème. Par exemple, l’activation de clients sur une connexion ou l’ajout d’URL de rappel à une application. Toutes les opérations dans Management API où vous devez récupérer une liste entière et la soumettre à nouveau avec la nouvelle valeur ajoutée sont des opérations qui doivent être effectuées en série afin d’éviter que deux opérations parallèles n’écrasent l’une des valeurs.
- Modifier le référentiel et redéployer : si vous utilisez l’outil Deploy CLI (ou une ligne de commande personnalisée) dans le cadre de votre pipeline CI/CD, vous préférerez peut-être envoyer vos modifications directement à votre référentiel, puis lancer un nouveau déploiement. Cela peut prendre un peu plus de temps, mais offre des avantages tels que la gestion de l’historique des versions et la possibilité de revenir en arrière en réimplantant une version antérieure. Vous pouvez avoir un référentiel séparé uniquement pour les éléments dont les organisations ont besoin afin de ne pas avoir à redéployer d’autres composants communs et risquer de commettre une erreur
Migration des utilisateurs
En plus d’héberger le profil utilisateur, Auth0 a également la capacité de servir de proxy pour votre propre ancien système de magasin d’identités et de fournir un remplacement sécurisé hébergé par Auth0. Ces deux fonctionnalités sont prises en charge via l’utilisation de connexions de la base de données d’Auth0. Si vous optez d’utiliser Auth0 en tant que remplacement de votre ancien magasin d’identités, vous pouvez migrer les utilisateurs soit d’un seul coup avec une migration en masse, soit progressivement avec une migration automatique.Meilleure pratique
Les clients optent souvent pour une approche en deux étapes de la migration des utilisateurs, en utilisant d’abord la migration automatique pour migrer autant d’utilisateurs que possible, puis la migration en bloc pour les utilisateurs restants. Voir Scénarios de migration des utilisateurs pour de plus amples informations. La migration automatique est souvent privilégiée, car elle permet de transférer les utilisateurs au fur et à mesure, tout en conservant leurs mots de passe dans la majorité des cas. Pour la migration en masse, nous vous recommandons d’utiliser la Management API au lieu de l’extension Importation/Exportation des utilisateurs dans la plupart des cas, sauf les plus simples, car Management API offre une plus grande flexibilité et un meilleur contrôle. Lors d’une migration en masse, les utilisateurs sont généralement tenus de réinitialiser leur mot de passe une fois la migration terminée, sauf si les mots de passe dans votre ancien magasin d’identités sont hachés en utilisant un des algorithmes pris en charge. Dans ce cas, vous pourrez peut-être utiliser la migration en masse et conserver les mots de passe des utilisateurs dans le cadre du processus, en fonction de l’algorithme et du nombre de tours de salage utilisés. Veuillez consulter Exemples de schémas de base de données d’importation en masse pour plus d’informations.L’importation de mots de passe hachés repose sur l’utilisation par le magasin d’identité source d’implémentations idiomatiques de l’un des algorithmes suivants : argon2, bcrypt, hmac, ldap, md4, md5, sha1, sha256, sha512, pbkdf2 et scrypt.
Meilleure pratique Les appels à Management API sont soumis à la [Politique de limite anti-attaques Auth0] (/support/policies/rate-limit-policy). Vous devez prendre cela en considération. Pour vous aider, Auth0 conseille généralement l’utilisation du Auth0 SKD qui convient pour votre environnement de développement plutôt que d’appeler nos API directement. :::
Proxy de magasin d’identités
Les types de connexion à la base de données Auth0 peuvent également être configurés pour servir de proxy à un magasin d’identités existant (ancien). Si vous devez conserver les identités des utilisateurs définies dans votre propre ancien magasin (par exemple, si vous avez une ou plusieurs applications critiques pour l’entreprise que vous ne pouvez pas migrer vers Auth0, mais qui nécessitent toujours un accès à ces identités), vous pouvez facilement les intégrer avec Auth0. Veuillez consulter Authentifier les utilisateurs à l’aide de votre base de données pour plus d’informations.Provisionnement des utilisateurs de l’organisation
Une organisation doit être directement liée à l’un de vos clients/partenaires commerciaux. Chaque entreprise/partenaire avec laquelle/lequel vous travaillez a des utilisateurs qui devront se connecter. Nous appelons ces utilisateurs finaux « utilisateurs de l’organisation ». Il existe deux approches différentes pour stocker les utilisateurs de votre organisation :- Isolés de l’organisation : Chaque utilisateur appartient uniquement à une seule organisation. Il ne serait pas logique qu’un utilisateur appartienne à plusieurs organisations. Et même si c’était le cas, il serait plus cohérent qu’il dispose d’une « identité » distincte pour chaque organisation. Par exemple, un employé de vente au détail travaillant à temps partiel dans deux magasins différents aurait deux identifiants de connexion distincts pour chaque magasin, même si les deux magasins utilisent la même application SaaS. Pour en savoir plus, veuillez consulter Provisionnement des utilisateurs isolés de l’organisation.
- Partagés entre les organisations : Dans un cas comme celui-ci, les utilisateurs créent leurs propres identifiants au sein de votre entreprise ou accèdent aux instances d’autres organisations utilisant votre application en se servant des identifiants de leur propre organisation. Une façon simple de voir les choses est qu’un utilisateur peut être autorisé à accéder à plusieurs instances de l’application appartenant à une organisation. Un utilisateur comprendrait qu’il peut utiliser les mêmes identifiants pour accéder aux deux instances d’une application. Par exemple, certains médecins ont des contrats avec plusieurs cliniques et peuvent avoir besoin de pouvoir se connecter à chaque clinique distincte avec leurs mêmes identifiants. Pour en savoir plus, veuillez consulter Provisionnement des utilisateurs partagés entre les organisations.
Provisionnement des utilisateurs isolés de l’organisation
Isoler les utilisateurs de l’organisation peut fournir une barrière propre et agréable entre les organisations. Si aucun utilisateur n’a besoin d’accéder à plus d’une organisation, ou si vous préférez les contraindre à créer plusieurs comptes, cette approche est intéressante. Vous devez provisionner ces utilisateurs au niveau du fournisseur d’identité. Chacune des organisations disposera de son propre fournisseur d’identité pour réaliser cette tâche. Ce fournisseur d’identité sera disponible sous l’une des trois formes suivantes :- Votre locataire Auth0 est le fournisseur d’identité : Une connexion à la base de données dans votre locataire principal dédiée à cette organisation.
- Les organisations apportent leur propre fournisseur d’identité : Vous configurez pour eux une connexion d’entreprise.
- Organisations avec plus d’un fournisseur d’identité : Vous activez plusieurs connexions d’entreprise, connexions sociales et pouvez également avoir une seule connexion à la base de données. Lorsque l’utilisateur sélectionne son organisation et essaie de se connecter, il pourra choisir parmi toutes les connexions disponibles pour cette organisation.
Meilleure pratique Si vous pouvez utiliser la fonctionnalité Organisations, cela simplifiera grandement votre système de connexion, le rendant plus facile à maintenir et à étendre à l’avenir. Voir Architecture des organisations multiples pour une compréhension plus approfondie. :::
Provisionnement des utilisateurs partagés entre les organisations
Lorsque vous partagez des utilisateurs entre des organisations, vous aurez besoin d’un moyen d’autoriser l’accès. Étant donné que vous ne saurez pas à quelle organisation un utilisateur peut appartenir lors de l’authentification, il est généralement recommandé de stocker vos utilisateurs dans un seul domaine, puis de déterminer leurs accès aux différentes organisations en les ajoutant en tant que membres de l’organisation. Pour cette raison, le provisionnement sera souvent effectué en commençant par un flux de travail d’invitation d’utilisateur pour la connexion de base de données unique, puis ils seront ajoutés à l’organisation à l’aide de Management API. Vous pouvez ensuite utiliser Management API pour récupérer les organisations auxquelles l’utilisateur appartient, si vous devez lui fournir une option pour passer d’une organisation à une autre.Limitations de dé-provisionnement
Auth0 ne communiquera pas avec le fournisseur d’identité en amont, si une session active avec Auth0 existe, sauf si vous le forcez avec uneprompt=login. Si l’une des organisations de votre client ne peut pas gérer la déconnexion pour ces utilisateurs, ceux-ci peuvent toujours y avoir accès après avoir été décommissionnés. Selon le fournisseur d’identité, si Auth0 obtient un jeton pour son API, vous pouvez demander des informations sur l’utilisateur fournisseur d’identité dans une règle afin de vérifier si cet utilisateur doit toujours avoir accès ou non. Si vous ne disposez pas de cette fonctionnalité, vous devrez offrir aux organisations clientes un moyen de bloquer ou de désactiver les utilisateurs de votre système, que ce soit par le biais d’un appel API ou d’une interface utilisateur.
Invitation de l’utilisateur
Dans la plupart des scénarios de commerce interentreprises, seules certaines personnes sont autorisées à accéder à l’application. Par conséquent, il est souvent plus simple de demander à un administrateur de créer des comptes d’utilisateur plutôt que de laisser les utilisateurs s’inscrire, puis de demander à un administrateur de les approuver. Le provisionnement peut souvent être effectué de manière automatisée lorsque des utilisateurs sont également ajoutés à un système centralisé. Il existe trois personnes différentes qui pourraient inviter les utilisateurs:- Un administrateur de votre entreprise peut créer les utilisateurs pour chaque organisation.
- Un administrateur de chaque organisation peut être désigné pour créer des utilisateurs.
- Un autre système responsable de la création d’utilisateurs peut exister, et ce système peut alors créer un utilisateur dans Auth0. Peu importe le public, la technique peut être similaire. Le reste est une question d’utilisation du bon modèle d’autorisation pour l’application.
user.email_verified défini sur false et un mot de passe temporaire aléatoire. Le mot de passe généré ne doit être connu que de Auth0 et ne doit pas être stocké dans un système externe ni transmis à l’utilisateur! Ensuite, utilisez Management API pour envoyer un courriel à l’utilisateur contenant un lien pour réinitialiser son mot de passe; vous pouvez même personnaliser le modèle de courriel dans Auth0 pour refléter le fait que cela fait également partie d’un processus de flux de travail d’inscription invité. Cela garantit que l’adresse électronique de l’utilisateur appartient à l’utilisateur créé et que la seule personne connaissant 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 ne doit connaître son mot de passe. Si vous utilisez un flux d’invitations, demandez à votre système dorsal de générer un mot de passe de manière aléatoire, puis de le rejeter et de demander à l’utilisateur de réinitialiser son mot de passe avant de se connecter. Ne créez pas un mot de passe temporaire que vous leur donnerez pour se connecter la première fois.
Inscription d’entreprise
L’inscription d’entreprise est synonyme de connexion via connexion entreprise — il n’y a aucune distinction ici en soi, car la création du profil utilisateur se fait automatiquement lors de la première connexion d’entreprise.Meilleure pratique Un avantage intéressant de permettre à vos clients d’utiliser leur propre fournisseur d’identité (IdP) est qu’ils peuvent gérer leurs utilisateurs, attribuer des rôles et des accès dans leur propre configuration de fournisseur d’identité (IdP), sans que vous ayez à créer une interface d’administration pour eux. Établir la correspondance/effectuer le mappage pour ces clients facilitera grandement les choses. :::
Si le mappage ne suffit pas et que vous devez introduire 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 pour la première fois. Par conséquent, vous devrez utiliser l’extensibilité des règles pour extraire les informations initiales d’un autre emplacement, ou forcer les utilisateurs à se connecter la première fois avant de pouvoir ajouter les métadonnées.