Vous devez vous assurer que votre personnel d’exploitation sait comment surveiller l’état du service Auth0 et qu’il a mis en place un moyen de s’abonner aux mises à jour de l’état d’Auth0.Le tableau de bord d’état d’Auth0, de même que le tableau de bord de disponibilité d’Auth0, présente l’état actuel et passé du service Auth0 dans un format facile à comprendre. Si des alertes de surveillance se déclenchent, votre personnel d’exploitation devrait, comme première étape du dépannage, vérifier le tableau de bord d’état pour voir s’il y a une panne en cours. La page d’état du nuage public permet aussi de s’abonner aux notifications de panne, et nous vous recommandons également de vérifier l’état de tout service externe tiers dont vous dépendez, comme les fournisseurs d’identité sociale. Avoir cette information à portée de main peut aider à éliminer rapidement les causes possibles lors du dépannage d’un problème et devrait figurer en tête d’une liste de vérification de dépannage pour les développeurs comme pour le personnel du centre d’assistance.
L’information sur la façon de vérifier l’état d’Auth0 ainsi que celui de tout service dont il dépend (comme les fournisseurs d’identité sociale) devrait figurer en tête d’une liste de vérification de dépannage pour les développeurs comme pour le personnel du centre d’assistance, et nous vous recommandons de vous abonner à la page d’état d’Auth0 afin de recevoir toute mise à jour d’état.
En cas de panne du service de nuage public, Auth0 effectue une analyse des causes fondamentales (RCA) et en publie les résultats sur la page d’état d’Auth0. Auth0 mène une enquête approfondie après une panne — y compris la détermination de la cause fondamentale, des facteurs contributifs et des moyens d’éviter que le problème ne se reproduise — et, par conséquent, la publication d’un document RCA peut prendre quelques semaines.
Vous devriez vous assurer que vous avez configuré votre propre fournisseur de courriel afin de prendre en charge les volumes de courriels en production qui pourraient être envoyés aux clients pour l’inscription, la validation du courriel, la récupération de compte et autres cas du genre.Auth0 envoie des courriels aux utilisateurs pour des événements comme les messages de bienvenue à l’inscription, la validation du courriel, les mots de passe compromis et la réinitialisation du mot de passe. Vous pouvez personnaliser les modèles de courriel pour chaque type d’événement, et il est aussi possible de personnaliser de façon avancée la gestion des courriels. Auth0 fournit un fournisseur de courriel de test à capacité limitée pour des tests de base, mais vous devez configurer votre propre fournisseur de courriel pour une utilisation en production, et la personnalisation des modèles de courriel ne fonctionnera pas tant que vous n’aurez pas configuré votre propre fournisseur.
Le fournisseur de courriel par défaut d’Auth0 ne prend pas en charge l’envoi de volumes de courriels de production ni la personnalisation des modèles de courriel. Vous devriez donc configurer votre propre fournisseur de courriel avant de déployer en production.
Si du code personnalisé exécuté dans Auth0 (par exemple dans une Action, une Rule, un Hook ou des scripts de base de données personnalisée) doit communiquer avec un service à l’intérieur de votre réseau, ou si vous configurez un fournisseur SMTP sur site dans Auth0, il se peut que vous deviez configurer votre pare-feu pour autoriser le trafic entrant depuis Auth0. Les adresses IP à autoriser dans le pare-feu varient selon la région et sont indiquées dans les écrans de configuration des Rules, des Hooks, des scripts de base de données personnalisée et du fournisseur de courriel dans votre .
Si votre environnement d’hébergement ne le gère pas automatiquement, vous devriez disposer de scripts qui redémarrent automatiquement NTP (Network Time Protocol) en cas de défaillance, ainsi que d’alertes pour aviser quelqu’un si NTP ne fonctionne pas. Les transactions d’authentification dépendent de l’exactitude de l’heure système, car les peuvent être jugés expirés au moment de leur réception s’il existe un décalage horaire entre les systèmes d’envoi et de réception.
Vérification des délais d’expiration du LoadBalancer
Si vous utilisez le connecteur AD/LDAP, vous devriez vérifier les paramètres du répartiteur de charge dans votre environnement pour voir s’il met fin aux connexions de longue durée lorsqu’elles sont inactives. Si c’est le cas, vous pouvez modifier les paramètres de la connexion AD/LDAP d’Auth0 afin d’utiliser le paramètre LDAP_HEARTBEAT_SECONDS pour envoyer périodiquement des messages de heartbeat et maintenir la connexion ouverte.
Si votre application conserve un état côté serveur au point de dépendre d’une répartition de charge persistante pour diriger les utilisateurs vers un serveur précis, il peut être utile de vérifier de nouveau que toutes les configurations du répartiteur de charge sont correctes. Un répartiteur de charge désynchronisé dans un groupe peut provoquer des erreurs intermittentes difficiles à diagnostiquer. Une vérification rapide de la configuration du répartiteur de charge peut éviter ce genre de problème dès le départ.
Vous devriez vérifier que vous avez mis en place la capacité de capter les données de journaux, que les journaux sont couverts par votre politique de conservation des données et que vous disposez de mécanismes pour faire respecter les limites de conservation des données de journaux. Vous devriez également vous assurer que vos équipes de développement, de soutien et de sécurité savent comment accéder aux données de journaux à des fins de dépannage et d’analyse judiciaire. L’exportation des fichiers journaux vers des services offrant des analyses complètes peut vous aider à repérer des tendances, comme les tendances d’utilisation et les erreurs.Auth0 offre de vastes capacités en matière de journalisation des événements, ainsi que d’analyse des journaux afin de repérer les anomalies d’événements (consultez la documentation sur les journaux pour en savoir plus). La période de conservation standard des journaux Auth0 est déterminée selon le niveau d’abonnement; la plus courte est de 2 jours et la plus longue, de seulement 30 jours. Tirer parti du soutien d’Auth0 pour l’intégration à des services de journalisation externes vous permettra de conserver les journaux au-delà de cette période et d’agréger les journaux à l’échelle de votre organisation.
Vous devriez tirer parti de l’une des solutions de diffusion des journaux pour envoyer les données de journaux à un service externe d’analyse de journaux. Cela permettra de conserver les données plus longtemps et de profiter d’analyses avancées sur les données de journaux.
Vous devriez examiner la période de conservation des données de journaux pour votre niveau d’abonnement et mettre en place une extension d’exportation des données de journaux afin d’envoyer les données de journaux à un service externe d’analyse de journaux. Vous pouvez utiliser l’une de nos solutions de diffusion des journaux dans Auth0 Marketplace.Les équipes de développement peuvent utiliser les fichiers journaux pour le dépannage et la détection d’erreurs intermittentes qui peuvent être difficiles à repérer au moyen des tests d’assurance qualité. Les équipes de sécurité voudront probablement disposer des données de journaux au cas où des données médico-légales seraient un jour nécessaires. L’exportation des fichiers journaux vers des services offrant des analyses complètes peut vous aider à repérer des tendances, comme les tendances d’utilisation et les .
Auth0 fournit un code d’erreur unique pour les erreurs signalées lorsque la limite de débit est dépassée. Vous devriez configurer une analyse automatique des journaux pour repérer les erreurs de limite de débit afin de pouvoir traiter de façon proactive l’activité qui dépasse ces limites avant qu’elle ne cause trop de problèmes à vos utilisateurs. Auth0 publie également des codes d’erreur pour d’autres types d’erreurs, et il est aussi utile d’analyser les journaux pour repérer les erreurs d’authentification ainsi que les erreurs liées aux appels à l’API (les codes d’erreur de la Management API sont affichés sous chaque requête dans le Management API Explorer).
Appeler la Management API pour récupérer les renseignements du profil utilisateur dans une Rule est une cause fréquente d’erreurs de limite de débit, car ces appels d’API peuvent s’exécuter à chaque connexion ainsi que lors des vérifications périodiques de la session.
Veillez à mettre en place une surveillance proactive du service Auth0, ainsi qu’une surveillance de bout en bout de l’authentification dans votre application.Vous devriez établir des mécanismes de surveillance des mises en œuvre d’Auth0, afin que votre équipe de soutien ou d’exploitation reçoive en temps voulu l’information nécessaire pour gérer les interruptions de service de façon proactive. Auth0 fournit des endpoints de surveillance qui peuvent être intégrés à votre infrastructure de surveillance. Ces endpoints sont conçus pour fournir une réponse adaptée aux services de surveillance. Il convient de noter qu’ils ne fournissent des données que sur Auth0. Pour une surveillance complète de bout en bout, essentielle pour vérifier la capacité des utilisateurs à se connecter, nous vous recommandons de mettre en place une surveillance des transactions synthétiques. Vous obtiendrez ainsi une surveillance plus granulaire et pourrez détecter les interruptions non liées à Auth0 ainsi que les baisses de performance, afin de réagir plus proactivement.
Vous devriez mettre en place la capacité d’envoyer des transactions de connexion synthétiques afin de faciliter la surveillance de bout en bout de l’authentification. Vous pouvez le faire à l’aide d’une application simple qui utilise le Resource Owner Password Grant en combinaison avec un utilisateur de test sans privilèges, sans oublier les politiques de limitation du débit d’Auth0.
Assurez-vous que votre équipe surveille tous les canaux de communication suivants d’Auth0 afin de rester au courant des annonces et des changements importants.Auth0 envoie plusieurs types de notifications que vous devriez surveiller, car elles contiennent des renseignements importants qui pourraient avoir une incidence sur vos tenant(s) et votre projet.
Auth0 envoie des notifications de sécurité proactives et d’autres annonces opérationnelles aux administrateurs du Dashboard. Assurez-vous que les personnes qui doivent recevoir ces messages sont des administrateurs du Dashboard.
De temps à autre, Auth0 peut envoyer un avis important lié à votre tenant. Ces avis concernant votre service seront envoyés dans votre Dashboard Auth0 et, selon leur gravité, par courriel aux administrateurs enregistrés du Dashboard Auth0. Vous devriez prendre l’habitude de vous connecter régulièrement au Dashboard et de vérifier l’icône de cloche en haut de la page pour voir s’il y a des avis importants. De plus, vous devriez consulter les courriels d’Auth0 rapidement, car ils peuvent contenir des renseignements importants sur des changements ou des actions que vous devez entreprendre.
Auth0 fournit de l’information sur les changements apportés au service dans le journal des modifications d’Auth0. Vous devriez prendre l’habitude de consulter régulièrement les journaux des modifications d’Auth0 afin de rester au fait des changements. Les équipes de soutien qui se penchent sur un problème peuvent trouver utile de consulter le journal des modifications pour déterminer si des changements récents pourraient être en cause, surtout s’il s’agit de changements incompatibles. Les équipes de développement voudront également consulter les journaux des modifications pour repérer de nouvelles fonctionnalités qui pourraient s’avérer utiles.De plus, vous devriez consulter périodiquement la page Migrations d’Auth0 pour vous tenir au courant des dépréciations à venir qui pourraient obliger votre équipe à apporter des changements.
Bien que ce ne soit pas obligatoire, nous vous recommandons de mettre en place un déploiement automatisé avec contrôle de version. L’automatisation du déploiement ou du rétablissement des changements dans les environnements de développement, de test et de production vous permet de réagir plus efficacement aux problèmes après le lancement.En plus d’adopter les pratiques exemplaires en matière de gestion des changements et d’assurance qualité, les clients qui réussissent intègrent aussi la gestion des ressources Auth0 à leur processus de déploiement automatisé. Comme il est indiqué dans la section Architecture, sous prise en charge du SDLC, vous devriez configurer des tenants Auth0 distincts pour les environnements de développement, de test et de production, avec la même configuration de tenant dans chaque environnement. L’automatisation du déploiement aide à garantir que la configuration du tenant demeure uniforme d’un environnement à l’autre, ce qui réduit les bogues et autres problèmes.
Quelle que soit la façon dont vous configurez l’automatisation du déploiement, nous vous recommandons d’effectuer des tests unitaires de vos rules, custom DB scripts et hooks avant le déploiement, puis d’exécuter aussi quelques tests d’intégration sur votre tenant après le déploiement. Pour en savoir plus à ce sujet, consultez les directives sur l’assurance qualité.
Auth0 prend en charge les approches suivantes d’automatisation du déploiement, qui peuvent être utilisées conjointement au besoin :
L’outil Auth0 Deploy CLI offre un script facile à utiliser qui s’intègre à votre pipeline existant d’intégration continue et de déploiement continu (CI/CD).
Les extensions de contrôle de code source d’Auth0 offrent un processus d’automatisation de base facile à mettre en place et nécessitant très peu de maintenance si vous n’avez pas de pipeline CI/CD, ou si vous ne pouvez pas vous intégrer directement à un pipeline CI/CD.
Si votre flux de travail de développement utilise Terraform, le Auth0 Terraform Provider vous aide à gérer les configurations de votre tenant Auth0.
Notez que l’outil Deploy CLI et les extensions de contrôle de code source peuvent tous deux entraîner des changements destructifs; les changements manuels apportés directement dans le dashboard entre les déploiements automatisés pourraient être perdus ! Pour cette raison, si vous utilisez l’un ou l’autre, tous les changements devraient être déployés à partir du système de contrôle de version utilisé par l’outil, et non apportés manuellement.
Chaque environnement peut aussi nécessiter une configuration propre à l’environnement — les et les de l’Application seront différents d’un tenant Auth0 à l’autre, par exemple — vous voudrez donc disposer d’un moyen d’y faire référence dynamiquement plutôt que d’avoir des valeurs codées en dur. Auth0 prend en charge la gestion de l’information de configuration propre à l’environnement au moyen de l’une des deux approches suivantes :
Auth0 vous permet de configurer des variables accessibles depuis l’extensibilité personnalisée; vous pouvez les considérer comme des variables d’environnement pour votre tenant Auth0. Au lieu de coder en dur des références qui changent quand vous déplacez du code entre les environnements de développement, de test et de production, vous pouvez utiliser un nom de variable configuré dans le tenant et référencé par le code d’extensibilité personnalisée. Il est ainsi plus facile d’utiliser le même code personnalisé, sans modification, dans différents tenants, puisque le code peut faire référence à des variables qui seront renseignées avec des valeurs propres au tenant au moment de l’exécution :
Pour utiliser des variables dans Actions, consultez Write Your First Action pour apprendre à configurer des secrets dans l’éditeur
Il est recommandé d’utiliser des variables pour stocker les valeurs propres au tenant, ainsi que tout secret sensible qui ne devrait pas être exposé dans votre code personnalisé. Si votre code personnalisé est déployé dans GitHub/GitLab/Bitbucket/VSTS, l’utilisation d’une variable propre au tenant permet d’éviter l’exposition de valeurs sensibles dans votre dépôt.
Vous devriez avoir un plan et un mécanisme en place pour assurer toute capacité de sauvegarde/restauration nécessaire à votre projet. Cela peut se faire à l’aide de l’Auth0 Management API pour les données, ainsi que des capacités d’Automated Deployment décrites dans la section sur le déploiement automatisé pour la configuration d’Auth0.Comme il est indiqué dans la politique de restauration des données du tenant d’Auth0 et la politique de transfert de données, Auth0 ne restaure pas les tenants supprimés et ne transfère pas les données entre les tenants. Auth0 fournit l’Auth0 Management API afin d’offrir aux clients une capacité entièrement flexible de sauvegarder, de restaurer et de transférer des données au besoin. Les clients peuvent écrire des scripts pour récupérer des données d’Auth0 à des fins de sauvegarde et, de la même façon, écrire des scripts à utiliser avec la capacité d’Automated Deployment pour restaurer n’importe quel aspect de leur configuration Auth0.
Vous devriez vérifier de nouveau que toutes les technologies de la pile de votre application, ainsi que les versions des navigateurs utilisés par vos utilisateurs, sont bien à jour, car cela aura une incidence sur la capacité d’Auth0 à fournir du soutien si des problèmes surviennent.
Vérifiez que vous utilisez la plus récente version prise en charge de node.js dans les paramètres du Dashboard Auth0.
Vérifiez que vous utilisez une version du SDK et des bibliothèques prise en charge par Auth0 selon la matrice de soutien d’Auth0.
Les certificats peuvent être utilisés dans les déploiements d’identité. Pour éviter qu’un certificat arrive à expiration à l’improviste, vous devriez avoir une liste des certificats de votre environnement, ainsi que leurs dates d’expiration, la façon dont vous serez avisé à l’approche de l’expiration et le déroulement du processus de remplacement des certificats.
Pour les connexions , vous obtenez un certificat auprès de l’ et vous le téléversez dans une connexion SAML pour l’IdP dans votre Auth0 Dashboard. Lorsqu’un de ces certificats est sur le point d’expirer, Auth0 enverra un courriel aux administrateurs du Dashboard pour les avertir de son expiration prochaine. Vous pouvez obtenir le nouveau certificat et le téléverser à l’aide de l’écran de configuration de la connexion.
Pour les (WS-Fed), si vous les configurez en indiquant une URL ADFS, toute modification sera prise en compte lors d’une mise à jour quotidienne. Vous pouvez aussi déclencher une mise à jour manuellement en ouvrant la page de configuration de la connexion dans le Dashboard Auth0 et en cliquant sur Save. Si un certificat est modifié du côté de l’IdP distant, Auth0 peut être mis à jour par ces mécanismes ou en téléversant un nouveau fichier de métadonnées dans le même écran de configuration de la connexion.
Plan de reprise après sinistre / plan de continuité des activités en place
Bien qu’il ne s’agisse pas d’une exigence absolue avant la mise en production, il est utile de disposer d’un plan de reprise après sinistre afin d’assurer la continuité des activités en cas de différents types de sinistres, notamment des pannes de système et des catastrophes naturelles frappant une région où se trouve du personnel clé.
Un autre point, sans être une exigence absolue, est néanmoins de veiller à ce que tous les processus liés à Auth0 soient documentés. Cela peut comprendre les éléments suivants :
Gestion des changements de configuration
Déploiement des nouvelles modifications et de tout mécanisme de déploiement automatique utilisé, ainsi que la façon de revenir à la version précédente en cas de problème
Processus de remplacement de certificat, s’il y a lieu
Ajout ou suppression de nouveaux fournisseurs d’identité, au besoin
Modifications de la structure du profil utilisateur dans Auth0 ou dans les répertoires dont Auth0 extrait les données
Ajout ou suppression d’applications ou d’API
Collecte et exportation des journaux
Processus de sauvegarde et de restauration que vous avez mis en place
Gestion des utilisateurs (mot de passe oublié, téléphone perdu)
Analyse des causes profondes à la suite d’un incident
Nous offrons des conseils de planification au format PDF que vous pouvez télécharger et consulter pour en savoir plus sur nos stratégies recommandées.Guide de planification de projet B2B IAM
Assistant
Responses are generated using AI and may contain mistakes.
