Authentification et accès

Cette fiche rassemble ce qui protège l'entrée dans l'ENT : comment un mot de passe est contraint, ce qui se passe quand on le tape mal plusieurs fois, ce qui est demandé en plus aux comptes d'administration, et ce qu'il reste d'une session après la déconnexion.

Les parcours eux-mêmes (créer un compte, l'activer, le bloquer, le supprimer) sont décrits ailleurs : Gestion des utilisateurs, Activation des comptes, Blocages temporaires.

Politique de mot de passe

Niveaux :1er degré2nd degré

Un mot de passe saisi par un utilisateur — à l'activation de son compte, à la réinitialisation, ou lors d'un changement volontaire — doit satisfaire une règle de robustesse. La règle n'est pas la même selon le degré, parce que le public ne l'est pas : un élève d'école élémentaire n'a pas la même capacité de mémorisation qu'un collégien, un enseignant ou un administrateur.

Public	Règle appliquée
Second degré, portails académiques, comptes d'administration	12 caractères au moins, dont une lettre minuscule, une lettre majuscule et un chiffre
Premier degré (thème openent1d)	6 caractères au moins, sans autre contrainte

La règle du second degré suit les recommandations de l'ANSSI pour un compte protégé par un mécanisme de blocage des tentatives — ce qui est le cas ici, cf. Après plusieurs échecs plus bas : c'est ce blocage qui rend inutile d'exiger, en plus, des caractères spéciaux.

Trois points qui évitent les mauvaises surprises :

• La règle s'applique aux mots de passe saisis ensuite, pas au stock existant. Mettre la règle en place ne rejette ni ne fait expirer les mots de passe déjà en usage : personne n'est déconnecté, et chacun bascule sur la nouvelle règle à son prochain changement.
• C'est le thème servi qui décide, c'est-à-dire l'adresse par laquelle on arrive. Une même plate-forme sert le premier et le second degré sous des hôtes différents ; la règle du premier degré s'applique aux personnes qui se connectent par l'hôte du premier degré.
• L'écran annonce exactement ce que le serveur applique : le message affiché sous le champ et le contrôle effectué à la validation sont issus de la même règle, résolue au même endroit. Il n'y a donc pas de cas où l'on annonce six caractères et où douze sont exigés.

Mots de passe déjà utilisés

Un nouveau mot de passe ne peut pas reprendre l'un des 10 précédents du même compte. L'ENT conserve pour cela l'empreinte des anciens mots de passe (jamais leur valeur en clair), et refuse la saisie avec un message explicite. La profondeur de l'historique est un paramètre de plate-forme (password-history-length, 10 par défaut).

Mot de passe provisoire du premier degré

Dans le parcours Mot de passe (primaire), l'enseignant crée pour l'élève un mot de passe provisoire, lisible à l'écran : six caractères, minuscules sans caractères ambigus et chiffres 3 à 9 — de quoi être recopié sans erreur par un enfant. Ce mot de passe est généré aléatoirement, vérifié contre la règle du degré concerné, et son changement est imposé à la première connexion.

Après plusieurs échecs

Concerne :Tous les profils

Au-delà de 5 tentatives de connexion infructueuses, l'identifiant est bloqué 15 minutes — paramètres maxRetry et banDelay. Le blocage porte sur l'identifiant et sur l'adresse IP d'origine, et s'efface tout seul à l'expiration du délai : il n'y a pas de compte à débloquer à la main.

Le détail (ce que voit l'utilisateur, ce que voit l'administrateur, la levée anticipée d'un blocage) est dans Blocages temporaires. Les tentatives refusées alimentent par ailleurs le journal Tentatives de connexion de la console d'administration, qui, lui, conserve un historique.

Second facteur pour les comptes d'administration

Concerne :Super-administrateurAdministrateur local

Un compte d'administration ouvre l'annuaire, les droits et les données de tout un établissement : son mot de passe seul ne suffit pas. L'ENT peut donc exiger un second facteur — un code à usage unique envoyé par courriel — avant de laisser accéder aux écrans sensibles.

Ce qu'il faut retenir :

• Seuls les comptes d'administration sont concernés : administrateur local (ADML) et super-administrateur. Aucun autre profil — élève, parent, enseignant, personnel — ne se voit jamais demander de second facteur.
• Le code est demandé une fois par session, au premier accès à un écran protégé, pas à chaque page.
• Les écrans protégés sont ceux qui touchent à l'annuaire, aux droits applicatifs, aux règles de communication, aux archives, au fil de nouveautés et à l'espace documentaire administrés.

Où l'activer, et où le lever

Le second facteur se règle à trois niveaux, du plus général au plus précis. Le plus précis l'emporte, et l'exigence l'emporte sur la dispense : en cas de réglages contradictoires, c'est l'issue la plus sûre qui est retenue.

Niveau	Effet
Plate-forme	active le mécanisme et choisit le canal (courriel). Sans lui, rien n'est demandé à personne
Établissement	dispense l'ensemble des administrateurs de cet établissement. La dispense ne vaut pour une personne que si tous ses établissements la portent
Compte	dispense un compte précis (compte de service, compte de test), ou au contraire exige de lui le second facteur même si son établissement en dispense

Ce dernier niveau existe pour une raison pratique : un établissement peut avoir à exempter ses comptes de service tout en imposant le second facteur à ses administrateurs réels — l'un ne va pas sans l'autre.

Une adresse de courriel est nécessaire

Le code part par courriel : un compte d'administration sans adresse renseignée ne peut pas le recevoir, et se retrouverait sans accès aux écrans protégés. Avant d'exiger le second facteur d'un établissement, vérifier que ses administrateurs ont bien une adresse — le script de déploiement activer_mfa_progressif.py liste ceux qui n'en ont pas.

État de la plate-forme

Le mécanisme est livré et configuré (canal courriel), et le déploiement est volontairement progressif : tous les établissements sont dispensés au départ, et le second facteur est exigé compte par compte, à mesure que les adresses de courriel sont vérifiées. Un établissement dispensé se comporte exactement comme avant.

Ce qui se passe à la déconnexion

Se déconnecter ne se contente pas de renvoyer à la page d'accueil :

• la session est détruite côté serveur — le jeton de session n'est plus reconnu, même présenté à nouveau ;
• les témoins de connexion sont effacés du navigateur (oneSessionId, authenticated) ;
• si la personne s'est connectée via un fournisseur d'identité externe (SAML ou OpenID Connect), la déconnexion lui est propagée — la déconnexion unique, ou SLO : sortir de l'ENT ne laisse pas une session ouverte chez le fournisseur.

Autrement dit, il ne subsiste, après déconnexion, aucune preuve d'authentification réutilisable — ni côté navigateur, ni côté serveur.

Une session est par ailleurs détruite à distance quand un administrateur bloque un compte : la personne est éjectée sans attendre l'expiration de sa session, cf. Bloquer un utilisateur.

Fournisseurs d'identité

L'ENT authentifie contre son propre annuaire, et sait déléguer l'authentification à un fournisseur externe (SAML 2.0, OpenID Connect, CAS). Il est alors fournisseur de service pour l'entrée des utilisateurs, et fournisseur d'identité pour les services qu'il expose — c'est ce second rôle qui permet d'arriver déjà authentifié sur NextCloud, le catalogue du CDI (PMB), Moodle ou un portail WordPress.

Le paramétrage des connecteurs (identifiant client, adresses de retour, portée, adresse de déconnexion) est décrit dans Gestion des applications.

Paramètres

Les paramètres cités (passwordRegex, passwordRegexBySkin, password-history-length, maxRetry, banDelay, mfaConfig) sont ceux du bloc auth d'ent-core.yaml. Ils valent pour la plate-forme entière, sauf mention explicite d'un réglage par établissement ou par compte.