Skip to main content

Statut

Vous devez vous assurer que votre équipe des opérations sait comment surveiller le statut du service Auth0 et qu’elle dispose d’un moyen de s’abonner aux mises à jour du statut d’Auth0. Le tableau de bord d’état d’Auth0, ainsi que le tableau de bord de disponibilité d’Auth0, affichent le statut actuel et passé du service Auth0 dans un format lisible par l’humain. Si des alertes de surveillance sont déclenchées, votre équipe des opérations 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 le statut de tous les services externes tiers dont vous dépendez, comme les fournisseurs d’identité sociale. Avoir cette information à portée de main peut aider à éliminer rapidement des 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.

Pratique exemplaire

Les renseignements sur la façon de vérifier le statut d’Auth0 ainsi que celui de tous les services dont il dépend (comme les fournisseurs d’identité sociale) devraient 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 des notifications en cas de mise à jour d’état.
En cas de panne du service en nuage public, Auth0 effectue une analyse des causes profondes (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’empêcher que le problème ne se reproduise — et, par conséquent, la publication d’un document de RCA peut prendre quelques semaines.

Configuration du fournisseur de courriel

Vous devriez vérifier de nouveau que vous avez bien configuré votre propre fournisseur de courriel pour prendre en charge les volumes de courriels de production qui pourraient être envoyés aux clients pour l’inscription, la validation des courriels, la récupération de compte et autres cas semblables. Auth0 envoie des courriels aux utilisateurs pour des événements comme le message de bienvenue à l’inscription, la validation des courriels, la détection de 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 le traitement des courriels. Auth0 fournit un fournisseur de courriel de test à capacité limitée pour les 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.

Pratique exemplaire

Le fournisseur de courriel par défaut d’Auth0 ne permet pas 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 le déploiement en production.

Infrastructure

Pare-feu

Si du code personnalisé exécuté dans Auth0 (par exemple dans une Action, une Rule, un Hook ou des Custom DB scripts) doit appeler un service sur votre réseau, ou si vous configurez un fournisseur SMTP sur site dans Auth0, vous devrez peut-être configurer votre pare-feu pour autoriser le trafic entrant provenant d’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, Hooks, custom database scripts et du fournisseur de courriel de votre .

NTP

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 panne, ainsi que d’alertes pour avertir quelqu’un si NTP ne fonctionne plus. Les transactions d’authentification dépendent de l’exactitude de l’heure système, car les peuvent être considérés comme expirés au moment de leur réception s’il y a un décalage entre l’heure des systèmes d’envoi et de réception.

Vérification des délais d’expiration de LoadBalancer

Si vous utilisez le connecteur AD/LDAP, vous devriez vérifier les paramètres du load balancer dans votre environnement pour voir s’ils interrompent les connexions inactives de longue durée. Si c’est le cas, vous pouvez modifier les paramètres de la connexion Auth0 AD/LDAP pour utiliser le paramètre LDAP_HEARTBEAT_SECONDS afin d’envoyer périodiquement des messages heartbeat et de garder la connexion ouverte.

Configuration de LoadBalancer

Si votre application conserve un état côté serveur au point de dépendre d’un Load Balancing persistant pour acheminer les utilisateurs vers un serveur précis, il peut être utile de revérifier que toutes les configurations du load balancer sont correctes. Un load balancer d’un groupe qui n’est pas synchronisé peut causer des erreurs intermittentes difficiles à diagnostiquer. Une vérification rapide de la configuration du load balancer peut éviter ce genre de problèmes dès le départ.

Journaux

Vous devriez vérifier que vous avez mis en place la capacité de capter les données de journalisation, 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 journalisation. Vous devriez aussi vous assurer que vos équipes de développement, de soutien et de sécurité savent comment accéder aux données de journalisation à 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 habitudes 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 plus de détails). La période de conservation standard des journaux Auth0 est déterminée selon le niveau d’abonnement, la période la plus courte étant de deux jours et la plus longue n’étant que de 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 limite et offrira aussi l’agrégation des journaux à l’échelle de votre organisation.

Pratique exemplaire

Vous devriez tirer parti de l’une des solutions de diffusion des journaux pour envoyer les données de journalisation à un service externe d’analyse de journaux. Cela permettra de conserver les données pendant de plus longues périodes et de bénéficier d’analyses avancées sur les données de journalisation.
Vous devriez passer en revue la période de conservation des données de journalisation pour votre niveau d’abonnement, et mettre en œuvre un service d’exportation de données de journalisation pour envoyer les données de journalisation à 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 pour détecter des erreurs intermittentes qui peuvent être difficiles à repérer au moyen des tests d’AQ. Les équipes de sécurité voudront probablement disposer des données de journalisation si des données médico-légales deviennent un jour nécessaires. L’exportation des fichiers journaux vers des services offrant des analyses complètes peut vous aider à voir des tendances comme les habitudes d’utilisation et les .

Limites de débit et autres erreurs

Auth0 fournit un code d’erreur unique pour les erreurs signalées lorsque la limite de débit est dépassée. Vous devriez mettre en place une analyse automatique des journaux afin de repérer les erreurs de limite de débit pour pouvoir intervenir de façon proactive sur l’activité qui atteint 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 provenant des appels à (les codes d’erreur de Management API sont affichés sous chaque requête dans le Management API Explorer).

Pratique exemplaire

Appeler la Management API pour récupérer les renseignements du profil utilisateur à partir d’une Rule est une cause fréquente d’erreurs de limite de débit, car ces appels d’API peuvent s’exécuter à chaque ouverture de session ainsi que lors des vérifications périodiques de session.

Surveillance

Assurez-vous de mettre en place une surveillance proactive du service Auth0, ainsi qu’une surveillance de l’authentification de bout en bout dans votre application. Vous devriez mettre en place des mécanismes de surveillance de vos 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 points de terminaison de surveillance qui peuvent être intégrés à votre infrastructure de surveillance. Ces points de terminaison sont conçus pour fournir une réponse exploitable par les services de surveillance. Il convient de noter qu’ils ne fournissent que des données sur Auth0. Pour une surveillance complète de bout en bout, essentielle pour vérifier que les utilisateurs peuvent se connecter, nous vous recommandons de mettre en place une surveillance des transactions synthétiques. Cela vous donnera une vue plus détaillée de votre surveillance et vous permettra de détecter les pannes non liées à Auth0 ainsi que les dégradations de performance, afin de réagir plus proactivement.

Pratique exemplaire

Vous devriez prévoir l’envoi de transactions de connexion synthétiques afin de faciliter la surveillance de bout en bout de l’authentification. Vous pouvez le faire avec une application simple qui utilise le Resource Owner Password Grant en combinaison avec un utilisateur de test sans privilèges, et n’oubliez pas non plus les politiques de limitation du débit d’Auth0.

Notifications d’Auth0

Vous devriez vous assurer 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 votre ou vos tenant(s) et sur votre projet.
Auth0 envoie des notifications de sécurité proactives et d’autres annonces opérationnelles aux administrateurs du dashboard. Vous devriez vous assurer que les personnes qui doivent recevoir ce type de messages sont des administrateurs du dashboard.

Notifications du Dashboard

À l’occasion, Auth0 peut envoyer une annonce importante concernant votre tenant. Ces annonces au sujet de votre service seront envoyées à votre Auth0 Dashboard et, selon leur gravité, par courriel aux administrateurs enregistrés de l’Auth0 Dashboard. Vous devriez prendre l’habitude de vous connecter régulièrement au Dashboard et de vérifier l’icône en forme de cloche en haut de la page pour voir s’il y a des avis importants. De plus, vous devriez consulter rapidement les courriels d’Auth0, car ils peuvent contenir des renseignements importants sur des changements ou des mesures que vous devez prendre.

Journal des modifications

Auth0 fournit de l’information sur les modifications apportées 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 pour rester au fait des changements. Les équipes de soutien qui enquêtent sur un problème peuvent trouver utile de consulter le journal des modifications afin de déterminer si des changements récents pourraient être en cause, surtout s’il s’agit de changements non rétrocompatibles. Les équipes de développement voudront aussi consulter les journaux des modifications pour repérer de nouvelles fonctionnalités qui pourraient être utiles. De plus, vous devriez consulter périodiquement la page Migrations d’Auth0 pour vous renseigner sur les dépréciations à venir qui pourraient obliger votre équipe à apporter des changements.

Déploiement automatisé, contrôle de version

Bien que ce ne soit pas obligatoire, il est fortement recommandé de mettre en place une automatisation du déploiement. Si vous automatisez le déploiement et l’annulation des changements dans les environnements de développement, de test et de production, vous pourrez réagir plus efficacement si des modifications doivent être apportées après le lancement. En plus d’adopter les meilleures pratiques en matière de gestion des changements et d’AQ, les clients qui réussissent intègrent aussi la gestion des ressources Auth0 à un processus de déploiement automatisé. Comme il est indiqué dans la section Architecture, sous SDLC support, vous devriez configurer des tenants Auth0 distincts pour les environnements de développement, de test et de production, et faire en sorte que cette configuration soit presque identique d’un tenant à l’autre. L’automatisation du déploiement aide à garantir cette cohérence, de sorte que le tenant de chaque environnement soit configuré de la même façon et que vous soyez moins susceptible de voir apparaître des bogues causés par des écarts de configuration entre les environnements.

Pratique exemplaire

Peu importe la façon dont vous configurez l’automatisation du déploiement, nous vous recommandons d’effectuer des tests unitaires sur vos rules, custom DB scripts et hooks avant le déploiement, puis d’exécuter également des tests d’intégration sur votre tenant après le déploiement. Pour en savoir plus à ce sujet, consultez les consignes Quality Assurance.
Auth0 prend en charge différentes options pour les approches d’automatisation du déploiement que vous pouvez utiliser, et chacune peut au besoin être utilisée conjointement avec l’autre :
  • L’outil Auth0 Deploy CLI fournit un script facile à utiliser qui peut vous aider à l’intégrer à votre pipeline d’intégration continue/déploiement continu (CI/CD) existant.
  • Si vous ne pouvez pas l’intégrer directement à un pipeline CI/CD, ou si vous n’en avez pas pour une raison ou une autre, les Source Control Extensions d’Auth0 peuvent fournir un processus d’automatisation de base, facile à configurer et nécessitant très peu de maintenance.
Notez que l’outil Deploy CLI et les source control extensions peuvent tous deux entraîner des changements destructifs; les changements manuels apportés directement dans le dashboard entre des déploiements automatisés pourraient être perdus! Pour cette raison, si l’un ou l’autre est utilisé, tous les changements doivent être déployés à partir du sous-système de contrôle de version référencé par l’outil, et non effectués manuellement.
Chaque environnement peut aussi nécessiter une configuration qui lui est propre — les et les seront différents d’un tenant Auth0 à l’autre, par exemple — vous aurez donc besoin d’un moyen d’y faire référence dynamiquement plutôt que d’utiliser des valeurs codées en dur. Auth0 prend en charge la gestion des renseignements de configuration propres à l’environnement au moyen de l’une des deux approches suivantes :

Variables propres au tenant

Auth0 vous permet de configurer des variables accessibles à partir de votre extensibilité personnalisée; elles peuvent être considérées comme des variables d’environnement pour votre tenant Auth0. Au lieu d’intégrer en dur des références qui changent lorsque le code passe d’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. Ainsi, le même code personnalisé peut fonctionner plus facilement, sans modification, dans différents tenants, puisque le code peut référencer 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 savoir comment configurer les secrets dans l’éditeur
  • Pour utiliser des variables dans Rules, voyez comment configurer des valeurs
  • Pour utiliser des variables dans Hooks, voyez comment configurer les secrets dans l’éditeur
  • Pour utiliser des variables dans Custom DB Scripts, consultez les paramètres de configuration

Pratique exemplaire

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.

Sauvegarde / restauration

Vous devriez avoir en place un plan et un mécanisme 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 de déploiement automatisé décrites dans la section sur le déploiement automatisé de la configuration d’Auth0. Comme indiqué dans la politique de restauration des données de tenant d’Auth0 et la politique de transfert de données, Auth0 ne restaure pas les tenants supprimés et ne déplace pas de 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 déplacer des données selon les besoins. 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é de déploiement automatisé pour restaurer n’importe quel aspect de leur configuration d’Auth0.

Versions à jour

Vous devriez vérifier de nouveau que toutes les technologies de la pile de votre application, ainsi que les versions de navigateur utilisées par vos utilisateurs, sont bien à jour, car cela peut avoir une incidence sur la capacité d’Auth0 à fournir du soutien si des problèmes surviennent.

Plan de rotation des certificats

Les certificats peuvent être utilisés dans des déploiements d’identité. Pour éviter qu’un certificat n’expire à votre insu, vous devriez tenir à jour une liste des certificats de votre environnement, avec leur date d’expiration, la façon dont vous serez avisé à l’approche de l’échéance et le déroulement du processus de rotation des certificats.

Connexions SAML

Pour les connexions , vous obtenez un certificat auprès de l’ et le téléversez dans une connexion SAML pour cet 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 l’expiration prochaine. Vous pouvez obtenir le nouveau certificat et le téléverser à partir de l’écran de configuration de la connexion.

Connexions WS-Fed

Pour les connexions , si vous les configurez en précisant une URL ADFS, toute modification sera prise en compte lors d’une mise à jour quotidienne. Vous pouvez déclencher une mise à jour manuellement en accédant à la page de configuration de la connexion dans l’Auth0 Dashboard et en cliquant sur Save. Si un certificat est modifié chez l’IdP distant, Auth0 peut être mis à jour par ces mécanismes ou par le téléversement d’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 que ce ne soit pas 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 touchant une région où se trouve du personnel essentiel.

Processus documentés

Un autre élément, qui n’est pas une exigence absolue mais qui est tout de même recommandé, consiste à veiller à ce que tous les processus liés à Auth0 soient documentés. Cela peut inclure ce qui suit :
  • 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 à une version précédente si des problèmes sont constatés
  • Processus de rotation des certificats, s’il y a lieu
  • Ajout ou suppression de nouveaux fournisseurs d’identité, le cas échéant
  • 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 logs
  • 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

Guide de planification de projet

Nous offrons un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons. Guide de planification de projet B2C IAM