Authentification à l’aide de votre propre magasin d’utilisateurs
La disponibilité varie selon le plan Auth0
Votre plan Auth0 ou votre accord personnalisé ont un impact sur la disponibilité de cette fonctionnalité. Pour en savoir plus, lisez Tarification.
Seuls les locataires créés avant le 17 juillet 2018 ont accès à Webtask.io et à l’interface de ligne de commande Webtask. Si vous êtes une entreprise cliente avec un nouveau locataire, veuillez communiquer avec votre représentant de compte pour demander l’accès. D’autres demandes peuvent être effectuées par l’entremise du Formulaire de contact Auth0 et seront évaluées au cas par cas.
Utilisez une connexion de base de données personnalisée lorsque vous souhaitez fournir un accès à votre propre magasin de données d’identité indépendant (hérité) pour les raisons suivantes :
Authentification : Utilisez votre base de données en tant que fournisseur d’identité dans Auth0 pour authentifier les utilisateurs. (Il s’agit de l’authentification traditionnelle).
Importer des utilisateurs : Utiliser la migration automatique (migration au compte-gouttes ou paresseuse).
Accès par procuration à un locataire Auth0 : Utiliser l’architecture multi-locataire Auth0.
Vous pouvez créer et configurer une connexion de base de données personnalisée en effectuant l’une des tâches suivantes :
Utilisez le point de terminaison Créer des connexions avec la stratégie
auth0.Naviguez vers Auth0 Dashboard > Authentification > Base de données, créez la connexion et activez l’option Utiliser ma propre base de données pour permettre l’édition du script d’action de la base de données.
Fonctionnement
Comme le montre le diagramme ci-dessous, vous utilisez des connexions de base de données personnalisées dans le cadre du flux de production de la connexion universelle afin d’obtenir des informations sur l’identité de l’utilisateur à partir de votre propre magasin d’identité.
Outre les artefacts communs à tous les types de connexions de base de données, une connexion de base de données personnalisée vous permet de configurer des scripts d’action : un code personnalisé utilisé lors de l’interface avec votre magasin d’identité existant. Auth0 fournit des modèles de script d’action de base de données personnalisée pour la configuration, et ceux que vous utiliserez dépendront du fait que vous créez une connexion de base de données personnalisée pour l’authentification héritée ou pour la migration automatique.
Meilleures pratiques
Les scripts d’action peuvent être mis en œuvre sous la forme de fonctions anonymes. Cependant, les fonctions anonymes compliquent le débogage lorsqu’il s’agit d’interpréter la pile d’appels générée à la suite d’une condition d’erreur exceptionnelle. Pour des raisons pratiques, nous recommandons d’établir un nom de fonction pour chaque script d’action.
Scénario d’authentification héritée
Dans un scénario d’authentification héritée, un nouvel enregistrement d’utilisateur est créé dans Auth0 lors de la première connexion de l’utilisateur, mais Auth0 ne stocke pas le hachage du mot de passe de l’utilisateur. Auth0 utilisera toujours le magasin d’identité hérité et l’identité qu’il contient lors de l’authentification de l’utilisateur.
Les connexions de base de données personnalisées sont également utilisées en dehors du flux de travail de la connexion universelle. Par exemple, le script d’actions changePassword d’une connexion est appelé lorsqu’une opération de changement de mot de passe se produit pour un utilisateur résidant dans un stockage d’identités existant.
Scénario de migration automatique
Lors d’une migration automatique, Auth0 crée un nouvel utilisateur dans un magasin d’identité (base de données) géré par Auth0. À partir de ce moment, Auth0 utilise toujours l’identité dans le magasin d’identité géré par Auth0 pour authentifier l’utilisateur. Pour ce faire, Auth0 exige d’abord que l’utilisateur soit authentifié par rapport au magasin d’identité hérité et ce n’est qu’en cas de succès que le nouvel utilisateur sera créé. Le nouvel utilisateur sera créé en utilisant le même identifiant et le même mot de passe que ceux fournis lors de l’authentification.
Meilleures pratiques
La création d’un utilisateur dans un scénario de migration automatique se produit habituellement une fois que le script d’action login se complète. Pour cette raison, nous recommandons que vous ne tentiez pas de supprimer l’utilisateur d’un magasin d’identités hérité en tant qu’opération incorporée (p. ex., dans le script login), mais plutôt d’effectuer la suppression dans un processus indépendant. Cela évitera de supprimer accidentellement un utilisateur en cas de condition d’erreur au cours du processus de migration.
Dans un scénario de migration automatique, les utilisateurs restent dans le magasin d’identité hérité et peuvent être supprimés ou archivés si nécessaire. Un effet secondaire peut se produire si un utilisateur est supprimé d’Auth0 mais reste présent dans le magasin d’identité hérité. Dans ce cas, une connexion effectuée par l’utilisateur supprimé pourrait entraîner l’exécution du script login et/ou getUser et la migration de l’utilisateur à partir de le magasin d’identité hérité.
Meilleures pratiques
Nous recommandons de marquer toute identité utilisateur héritée comme ayant été migrée avant que le script login ou getUser ne soit terminé ou avant toute suppression éventuelle de l’ancien magasin.
Taille
La taille totale de la mise en œuvre d’un script d’action ne doit pas dépasser 100 Ko. Plus la taille est importante, plus cela introduit de la latence en raison du processus de conditionnement et de transport utilisé par la plateforme Webtask sans serveur Auth0, ce qui aura des répercussions sur les performances de votre système.
La limite de 100 k0 n’inclut pas les modules npm qui peuvent être référencés dans le cadre d’une déclaration d’exigence.
Environnement
Les scripts d’action s’exécutent comme une série de fonctions appelées JavaScript dans une instance d’un conteneur Webtask sans serveur. Dans ce cadre, un environnement particulier est fourni, ainsi qu’un certain nombre d’artefacts issus à la fois du conteneur Webtask et du serveur d’authentification Auth0 (votre locataire Auth0) lui-même.
modules npm
Les conteneurs Webtask sans serveur Auth0 peuvent utiliser une vaste gamme de modules npm; npm les modules ne réduisent pas seulement la taille globale de l’implémentation du code du script d’action, mais fournissent également un accès à une large gamme de fonctionnalités préconstruites.
De nombreux modules npm accessibles au public sont pris en charge dès le départ. La liste a été compilée et vérifiée pour tout problème de sécurité potentiel. Si vous avez besoin d’un module npm qui n’est pas pris en charge dans la boîte, vous pouvez en faire la demande à partir du portail d’assistance d’Auth0 ou votre représentant Auth0. Auth0 évaluera votre demande pour déterminer si elle est appropriée. Auth0 n’offre actuellement aucun support à l’utilisateur de modules npm provenant de dépôts privés.
Variables
Les scripts d’action d’Auth0 prennent en charge les variables d’environnement, accessibles à partir de l’objet configuration accessible dans le monde entier. Pour en savoir plus, lisez la section Ajouter des paramètres de configuration dans Créer des connexions de base de données personnalisées.
Meilleures pratiques
L’objet de configuration devrait être traité en lecture seule, et devrait être utilisé pour stocker des informations sensibles comme des authentifiants ou des clés API permettant d’accéder à des magasins d’identité externes. Cela empêchera d’avoir des valeurs sensibles du point de vue de la sécurité codées en dur dans un script d’action.
L’objet de configuration peut également être utilisé pour soutenir les stratégies Cycle de vie du développement logiciel que vous employez en vous permettant de définir des variables ayant des valeurs spécifiques au locataire. Cela permet d’éviter les valeurs codées en dur dans un script d’action qui peuvent changer en fonction du locataire qui l’exécute.
objet global
Les conteneurs Webtask sans serveur Auth0 sont fournis à partir d’une banque associée à chaque locataire Auth0. Chaque instance de conteneur met à disposition l’objet global, auquel il est possible d’accéder à travers tous les scripts d’action qui s’exécutent dans l’instance de conteneur. L’objet global agit comme une variable globale unique au conteneur, qui peut être utilisée pour définir des informations ou des fonctions utilisées dans tous les scripts d’action qui s’exécutent dans l’instance de conteneur.
Cela signifie que l’objet global peut être utilisé pour mettre en cache des ressources coûteuses tant que ces ressources ne sont pas propres à l’utilisateur. Par exemple, vous pouvez l’utiliser pour stocker un jeton d’accès à une API tierce (de journalisation) qui fournit des fonctionnalités non propres à l’utilisateur. Vous pouvez également stocker un jeton d’accès à votre propre API non propre à l’utilisateur, définie dans Auth0 et obtenue à partir du flux des identifiants client.
Un script d’action peut s’exécuter dans n’importe quelle instance de conteneur déjà en cours d’exécution ou dans une instance de conteneur nouvellement créée (qui peut être ajoutée ultérieurement au groupe). Aucune affinité de conteneur n’existe pour l’exécution de scripts d’action dans Auth0. Cela signifie que vous devez éviter de stocker des informations spécifiques à l’utilisateur dans l’objet global et devez toujours vous assurer que toute déclaration faite dans l’objet global prévoit également l’initialisation.
Chaque fois qu’un conteneur de tâches Web est recyclé, ou pour chaque instanciation d’un nouveau conteneur de tâches Web, l’objet global qu’il définit est réinitialisé. Ainsi, toute déclaration d’affectation dans l’objet global associé à un conteneur doit également prévoir l’initialisation.
Meilleures pratiques
Pour fournir une flexibilité au niveau de la performance, les conteneurs Webtask sans serveur sont provisionnés dans Auth0 sur une base ad hoc et sont également soumis à diverses politiques de recyclage. En général, nous vous recommandons de ne pas considérer la durée de vie d’un objet globalcomme étant supérieure à 20 minutes.
Sécurité
Accès au stockage des identités héritées à partir d’une API personnalisée
Protéger le stockage des identités existantes contre un accès général est une bonne pratique recommandée. Exposer une base de données directement à l’Internet, par exemple, peut être extrêmement problématique : les interfaces de base de données pour SQL et autres sont extrêmement ouvertes en termes de fonctionnalité, ce qui viole le principe du moindre privilège lorsqu’il s’agit de sécurité.
Meilleures pratiques
Nous recommandons que vous implémentiez une API pour accorder des privilèges limités à votre magasin d’identités hérité (base de données), plutôt que de simplement ouvrir un accès général via Internet.
La solution de rechange consiste à créer une API simple (personnalisée), protégée par l’utilisation d’un jeton d’accès, que chaque script d’action peut appeler. Cette API servira d’interface avec le magasin d’identité hérité. Le flux d’octroi des identifiants client peut alors être utilisé pour obtenir un jeton d’accès à partir d’un script, qui peut ensuite être mis en cache pour être réutilisé dans l’objet global afin d’améliorer les performances. L’API peut alors fournir un nombre discret de points de terminaison protégés qui n’exécutent que la fonctionnalité de gestion héritée requise (p. ex., read user, change password).
Meilleures pratiques
Par défaut, Auth0 vous donnera un jeton pour toute API si votre authentification est réussie et inclut le public adéquate. Le fait de restreindre l’accès à l’ancienne API du magasin d’identités en limitant l’attribution de jetons d’accès au moyen d’une règle empêchera toute utilisation non autorisée et atténuera un certain nombre de scénarios de vecteurs d’attaque, tels que lorsque la redirection vers /authorizeest interceptée et l’audience à l’API ajoutée.
Autoriser l’accès au stockage d’identités hérité
Peu importe que vous gériez l’accès à un magasin d’identité hérité au moyen d’une API personnalisée ou que vous utilisiez l’interface native fournie, vous devez restreindre l’accès à la liste des adresses IP associées à votre locataire Auth0. Ajout à la liste d’autorisation restreint l’accès au magasin d’identité hérité en veillant à ce que seuls les scripts d’action de base de données personnalisés définis dans Auth0 soient autorisés.
La liste d’autorisation (AllowList) des adresses IP d’Auth0 est partagée avec tous les locataires Auth0 définis pour une région. N’utilisez jamais la liste d’autorisation comme seule méthode pour sécuriser l’accès à votre magasin d’identités hérité : vous risqueriez d’ouvrir des failles de sécurité potentielles permettant un accès non autorisé à vos utilisateurs.