Principes des logs d'authentification

Les demandes d'authentification sur la WebUI peuvent venir de plusieurs points d'entrées :

  • Une connexion sur l'interface de visualisation
  • Un appel aux URL des pages de reporting

Les logs sont regroupé par le tag "AUTHENTICATION" suivi du tag "REPORTING" pour les appels sur les URL de REPORTING ou du tag comportant le nom de la WebUI pour les connexions sur les interface de visualisation.

Afin de pouvoir suivre une demande d'authentification sans tracer l'utilisateur un uuid est généré par connexion. Cela est nommé "authentication phase"

Afin de respecter la Réglementation Générale sur la Protection des Données,

  • les logs en INFO ne doivent pas identifier un utilisateur mais juste tracer une connexion
  • les logs en WARNING, DEBUG ou ERREURS peuvent afficher des informations sur les utilisateurs car ces logs sont utiliser à des fins de diagnostique de l'application


La WebUI initie donc les logs et demande a chacun des modules d'authentification configurés dans son CFG d'authentifier l'utilisateur. Les logs concernant chacun des modules se trouve dans leur page.

Lors de cet appel aux sous modules, la WebUI donne:

  • le couple login/password
  • un loger contenant le tag AUTHENTICATION et l'origine de la demande d'authentification
  • le "authentication phase id", permettant de suivre la demande dans les sous-module


Descriptions des logs

Initialisation de la demande d'authentification

Un premier log permet d'initialiser une "authentication phase" avec un identifiant.

"L'authentication phase id" est généré aléatoirement sans prendre en compte les données de l'utilisateur. Cet identifiant unique permet seulement de suivre une requête de connexion sans pouvoir identifier un utilisateur. Si le même utilisateur se connecte une seconde fois ou sur un autre poste, l'identifiant généré sera totalement différent.


[YYYY-MM-DD HH:MM:SS] INFO   : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] Need to check a user authentication ( authentication phase id-eaa09e3a8b2d11eb937a080027cc5994 )

un log de DEBUG nous permet de connaître le nom d'utilisateur renseigné et depuis quelle source il se connecte

[YYYY-MM-DD HH:MM:SS] DEBUG  : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] A user try to connect from address 192.168.1.82 with username groy-ldap ( authentication phase id-b6a7f0ae8bc511ebb37a080027cc5994 )


Parcours des modules possédant la fonction "check_auth" pour authentifier les utilisateurs

La WebUI va ensuite parcourir tous ses sous-modules et demander à tous ceux qui ont la fonction "check_auth" d'authentifier les utilisateurs:


[YYYY-MM-DD HH:MM:SS] INFO   : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] Use module auth-active-directory to authenticate user ( authentication phase id-b6a7f0ae8bc511ebb37a080027cc5994 )
  • si le module a authentifier l'utilisateur, la WebUI l'indique et la phase d'authentification est terminée
[YYYY-MM-DD HH:MM:SS] INFO   : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] The user has been authenticated by the module auth-active-directory ( authentication phase id-b6a7f0ae8bc511ebb37a080027cc5994 )
  • si le module n'a pas put authentifier l'utilisateur ( quelque soit la raison ), elle l'indique et recherche un autre module qui puisse authentifier l'utilisateur
[YYYY-MM-DD HH:MM:SS] INFO   : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] Module auth-active-directory didn't authenticate user ( authentication phase id-b6a7f0ae8bc511ebb37a080027cc5994 )