Összehasonlított verziók

Régi verzió 4

changes.mady.by.user Guillaume ROY

Mentés ekkor:

összehasonlítva

Új verzió Aktuális

changes.mady.by.user benjamin martin

Mentés ekkor:

Kulcs

  • Beillesztett sor.
  • Törölt sor.
  • Formázás megváltoztatva.


Scroll Ignore
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltrue


Panel
titleSommaire

Page Treetoc
rootstyle@selfnone



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 visualisationVisualisation
  • 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é

  • Pour le suivre il suffit de rechercher "authentication phase id-XXXX", XXXX étant une chaîne alphanumérique ( Ex : id-eaa09e3a8b2d11eb937a080027cc5994 )

Info

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 ERROR peuvent afficher des informations sur les utilisateurs, car ces logs sont utiliser utilisés à des fins de diagnostique diagnostic de l'application


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

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

  • le couple login/password
    • un loger contenant le tag AUTHENTICATION et

    Descriptions des logs

    Tous les logs d’authentification seront regroupés sous le chapitre [ AUTHENTICATION ] 

    Suivant 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

    , le chapitre suivant sera :

    • [ UI Visualization ] : Une connexion sur l'interface de Configuration
    • [ REPORTING ] : Un appel sur les URLs de génération de rapport

    Exemple :

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

    Info"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.

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


    Initialisation de la demande d'authentification

    Un premier log permet d'initialiser une "authentication phase" avec un identifiant.un log de DEBUG nous permet de connaître le nom d'utilisateur renseigné et depuis quelle source il se connecte

    Code Block
    themeEmacs
    [YYYY-MM-DD HH:MM:SS] INFO DEBUG  : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] ANeed user try to connectcheck froma address 192.168.1.82 with username groy-ldapuser authentication ( authentication phase id-b6a7f0ae8bc511ebb37a080027cc5994eaa09e3a8b2d11eb937a080027cc5994 )


    Info

    L'authentification 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é est totalement différent.


    Parcours des

    modules possédant la fonction "check_auth"

    sous-modules 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 :

    Code Block
    themeEmacs
    [YYYY-MM-DD HH:MM:SS] INFO   : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] Use module "auth-active-directory" to authenticate user ( authentication phase id-b6a7f0ae8bc511ebb37a080027cc5994 )


    Authentification réussie

    Si le sous-

    si le

    module a

    authentifier

    authentifié, l'utilisateur, la WebUI l'indique

    et la phase d'authentification est terminée

    :

    Code Block
    themeEmacs
    [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


    Authentification échouée

    Si aucun des sous-modules n'a

    pas put authentifier

    authentifié l'utilisateur

    ( quelque soit la raison ), elle l'indique et recherche un autre module qui puisse authentifier l'utilisateur

    , alors un log d'info va afficher qu'un utilisateur n'a pas pu se connecter :

    Code Block
    themeEmacs
    [YYYY-MM-DD HH:MM:SS] INFO   : [ MODULE-NAME ] [ AUTHENTICATION   ] [ UI Visualization ] Module auth-active-directory didn'tWe tried to authenticate the user with all active module but it failed. AUTHENTICATION FAILED ( authentication phase id-b6a7f0ae8bc511ebb37a080027cc5994 )