Connexion et authentification

Vue d’ensemble — à quoi cela sert

InfraGuard possède deux plans d’authentification :

1. Console web = connexion par session. Un exploitant se connecte avec login_id + password et AuthController crée une session maison. Chaque page de la console traverse ensuite le middleware infr.auth (InfrAuth), qui vérifie la session et relit dans la base de données le niveau, le nom et la langue de l’utilisateur à chaque requête afin de garder la copie stockée en session à jour.
2. API d’ingestion externe = clé d’API sans état (bearer). Lorsqu’une application externe publie des incidents, des comptes rendus de sauvegarde ou des analyses de sécurité, elle s’authentifie avec un jeton de clé d’API (Authorization: Bearer … ou X-Infr-Api-Key) via le middleware infr.apikey, et non par une session. Pas de session, pas de CSRF.

Caractéristiques principales :

• Resynchronisation de la session — lorsqu’un administrateur modifie le niveau, le nom ou la langue d’un utilisateur, cela prend effet dès la requête suivante, sans reconnexion.
• Application au niveau des URL — masquer des entrées de menu ne suffit pas. Des groupes de routes comme /security, /backup et /admin imposent le niveau minimal directement sur l’URL grâce au middleware infr.level:N.
• Actions destructrices = nouvelle vérification du niveau + audit — bloquer, restaurer, modifier des paramètres, etc. sont protégés par une barrière de niveau d’écriture, un enregistrement dans infr_audit_log et une confirmation dans l’interface.

Quand l’utiliser

• Vous vous connectez à la console pour la première fois, ou vous avez été soudainement renvoyé vers /login et souhaitez comprendre pourquoi.
• Vous raccordez une application Laravel externe à l’API d’ingestion d’incidents ou à l’intégration du compte rendu de sauvegarde et devez savoir quel en-tête l’authentifie.
• Un administrateur a modifié un niveau, un nom ou une langue et vous devez expliquer pourquoi aucune reconnexion n’est nécessaire.

Disposition

L’écran de connexion (/login) est une simple carte unique.

Le formulaire de connexion porte un jeton @csrf Blade standard. La console est protégée par session + CSRF et ne demande aucun jeton bearer distinct dans l’interface.

Comment l’utiliser

Se connecter

1. Rendez-vous sur /login (si vous êtes déjà connecté, vous êtes redirigé vers /).
2. Saisissez votre Login ID et votre Password.
   • Validation : login_id 60 caractères au maximum, password de 4 à 120 caractères.
3. Cliquez sur Se connecter. Le serveur recherche le compte dans infr_user par login_id + is_close=0 et vérifie le mot de passe.
4. En cas de succès, la session est régénérée (session()->regenerate()) et vous êtes envoyé vers next (ou /).

Une connexion réussie renseigne ces clés de session :

La colonne last_log est également horodatée à l'heure actuelle.

Se déconnecter

• Utilisez l’entrée Déconnexion du menu déroulant utilisateur de la barre supérieure (ou POST /logout).
• Le serveur oublie infr_user_id, invalide la session, régénère le jeton CSRF et redirige vers /login.

Durée de vie de la session et resynchronisation à chaque requête

Chaque page de la console traverse infr.auth (InfrAuth), qui, à chaque requête :

1. Recharge l’utilisateur à partir du infr_user_id de la session (chemin critique, colonnes minimales : id · login_id · name · email · user_level · role_id · team_id · lang · avatar · is_close).
2. Si le compte est absent ou en is_close=1 (désactivé), détruit la session et redirige vers /login (ou renvoie un 401 JSON).
3. Écrase infr_user_level · infr_name · infr_lang avec les valeurs de la base, si bien qu’un changement de niveau, de nom ou de langue par un administrateur se reflète dès la requête suivante sans reconnexion.
4. Range le modèle utilisateur dans l’attribut de requête infr_user et fixe la langue d’affichage via app()->setLocale().
5. Appelle OpsPolicy::markPresence() pour enregistrer la présence (le mode économie de la politique d’exploitation s’en sert pour décider qu’« un utilisateur de la console est actif en ce moment » et conditionner la collecte de la base — voir Politique d’exploitation).

La durée de vie de la session suit SESSION_LIFETIME (120 minutes par défaut).

La connexion à la console ne comporte pas de case « se souvenir de moi » distincte. La session dure le temps indiqué ci-dessus ; une fois expirée, vous devez vous reconnecter.

Authentification de l’API d’ingestion externe (clé bearer)

Lorsqu’une application externe publie sur /api/v1/*, elle s’authentifie avec une clé d’API (sans état — ni session, ni CSRF).

Comportement :

• Le serveur convertit le jeton reçu en hachage et le compare en temps constant (une comparaison à temps constant) à infr_api_key.key_hash (clés actives uniquement). La clé en clair n’est jamais stockée.
• Limite de 120 requêtes par minute et par clé. Au-delà, la réponse est 429 rate_limited avec un en-tête Retry-After.
• Chaque appel met à jour last_used_at · last_used_ip · use_count.

Principaux points de terminaison :

# Vérification de la connectivité / de la clé
curl -sS https://infraguard.example.com/api/v1/ping \
  -H "Authorization: Bearer YOUR_KEY"

# Enregistrer automatiquement un incident (dédoublonné · source=pulse)
curl -sS -X POST https://infraguard.example.com/api/v1/incidents \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"NPE in checkout","fingerprint":"abc123","severity":"crit"}'

Émettez, révoquez les clés et copiez le code d’intégration dans Administration ▸ Clés API (la clé en clair n’est affichée qu’une seule fois, à l’émission).

Step-up — protéger les actions destructrices

Les actions à risque telles que bloquer, débloquer, restaurer ou modifier des paramètres sont protégées — non pas par une nouvelle saisie du mot de passe — mais par trois défenses :

1. Nouvelle vérification du niveau — les actions d’écriture exigent au moins le niveau d’écriture (2 ou plus) et les actions d’administration exigent le niveau administrateur (10), revérifiés côté serveur.
2. Journal d’audit — les valeurs avant/après, ainsi que l’auteur et l’adresse IP, sont écrites dans le journal d’audit (infr_audit_log).
3. Confirmation dans l’interface — une boîte de dialogue de confirmation (step-up) garde l’action à l’écran.

Sources de données

La colonne infr_user.password n’est jamais exposée dans les journaux, les URL ni les cookies. La clé d’API en clair n’est montrée qu’à l’émission ; la base ne conserve que le hachage.

Accès

• /login · /logout — accessibles à tous (invité).
• Toute la console — exige une session valide (infr.auth). Sans elle, les requêtes de page redirigent vers /login et les requêtes AJAX reçoivent 401 unauthenticated.

Barrières au niveau des URL (évaluées après la connexion) :

Paliers de niveau : demo=1 · staff=5 · admin=10. Voir Niveaux d’accès pour la politique complète.

Dépannage et FAQ

Je me connecte mais je suis sans cesse renvoyé vers /login. Le cookie de session n’est pas conservé (domaine ou SESSION_DOMAIN incohérent, ou cookie réservé à HTTPS servi en HTTP), ou le compte a été mis à is_close=1 (désactivé). Demandez à un administrateur de vérifier l’état du compte.

Je vois « Ces identifiants ne correspondent pas à nos enregistrements. » Une faute de frappe dans login_id, un mauvais mot de passe ou un compte désactivé (is_close=1). Par sécurité, le message ne précise pas lequel.

Un compte n’arrive pas à se connecter. Le mot de passe est peut-être incorrect ou le compte désactivé. Un administrateur réinitialise le mot de passe dans Utilisateurs et équipes.

Je peux me connecter mais pas ouvrir /admin. Votre niveau est inférieur à 10. /admin est gardé par infr.level:10 ; seuls les administrateurs y accèdent. De même, /security et /backup exigent le niveau 2 ou plus.

Un appel AJAX renvoie 401. La session de la console a expiré. Rechargez la page et reconnectez-vous. Les requêtes JSON reçoivent {"error":"unauthenticated"} en 401 au lieu d’une redirection.

Un administrateur a relevé mon niveau mais cela ne s’est pas appliqué. InfrAuth resynchronise la session à chaque requête : cela s’applique donc dès la navigation suivante, sans reconnexion. Rechargez pour l’appliquer tout de suite.

Le menu ou l’interface est dans une langue inattendue. La langue d’affichage suit infr_user.lang (clé de session infr_lang) et se resynchronise à chaque requête. Changez-la dans Localisation.

L’API renvoie 401 invalid_api_key / 429 rate_limited. Une clé inactive ou mal saisie donne un 401 ; plus de 120 requêtes par minute donnent un 429 (+ Retry-After). Vérifiez l’état de la clé dans Clés API et ralentissez le rythme.

Voir aussi

• Niveaux d’accès — user_level ↔ min_req, paliers demo/staff/admin
• Rôles et équipes — portée des rôles et propriété des équipes
• Gestion des utilisateurs et des équipes — créer des comptes, réinitialiser des mots de passe, désactiver
• Clés API — émettre des clés pour l’API d’ingestion et code d’intégration
• Localisation — langue d’affichage et repli de locale
• Journal d’audit — suivi des actions destructrices