Set-OPS-Public/docs/authentification.md

Authentification : Keycloak devant, LDAP dessous, sudo en secours

Directive d'architecture du 2026-08-03. Trois règles, décidées ensemble et volontairement indissociables — chacune crée le problème que la suivante résout.

1. Toute authentification web passe par Keycloak. Aucun service ne tient son propre répertoire de comptes.
2. LDAP est la source de vérité unique des comptes d'un tenant. Keycloak le fédère ; les protocoles qui ne parlent pas OIDC s'y lient directement.
3. Chaque service garde un accès de secours, atteint par sudo sur l'hôte.

1. Pourquoi les trois vont ensemble

La chaîne est en série : service → Keycloak → LDAP. C'est ce qui donne « une identité, un mot de passe » — et c'est aussi trois points de panne alignés. Si LDAP tombe, plus personne n'entre nulle part, y compris pour réparer.

La règle 3 n'est donc pas une entorse au SSO : c'est ce qui rend les deux premières tenables. Sans elle, la panne d'un maillon devient une exclusion totale.

2. Portée : le web, et seulement le web

Protocole	Chemin d'authentification	Pourquoi
HTTP(S) — interfaces humaines	Keycloak (OIDC natif, ou oauth2-proxy devant)	c'est là que la directive s'applique
IMAP / SMTP	LDAP direct (Dovecot, Postfix)	ces protocoles ne parlent pas OIDC ; le flux est prouvé de bout en bout
SSH	clé publique (PasswordAuthentication no)	pas de mot de passe du tout, donc rien à fédérer
PostgreSQL, Redis	secrets applicatifs en voûte	comptes de service, pas d'humains

Ce qui est interdit partout, c'est qu'un service tienne son propre répertoire d'humains. Le chemin varie ; la source ne varie pas.

3. La posture retenue : la porte de secours n'est pas annoncée

Le compte local de chaque service existe — il ne peut pas dépendre de Keycloak, sinon il tomberait avec lui. Mais son formulaire de connexion n'est pas proposé au repos.

Ce n'est pas une préférence esthétique. Un formulaire local ouvert en permanence :

• contourne la politique de mot de passe et le MFA ;
• contourne surtout la révocation centrale — désactiver quelqu'un dans LDAP laisserait son compte local valide, sans que rien ne le signale ;
• offre une cible de bourrage d'identifiants sur admin, en continu, pour un usage qui devrait être exceptionnel.

Le coût de la fermeture est nul depuis qu'on a tranché que sudo suffit : sudo est le mécanisme de réouverture.

Ce que chaque service sait vraiment faire

Vérifié auprès de l'amont le 2026-08-03, puis par rendu réel des gabarits dans les deux postures — pas seulement lu.

Service	Réglage	Effet réel	Secours par sudo
Grafana	GF_AUTH_DISABLE_LOGIN_FORM=true	ferme le formulaire	grafana-cli admin reset-admin-password
Forgejo ≥ 10	ENABLE_INTERNAL_SIGNIN=false + ENABLE_BASIC_AUTHENTICATION=false	ferme la connexion interne et l'API en Basic	forgejo admin user change-password
Nextcloud	hide_login_form=true	masque seulement	occ user:resetpassword, ou …/login?direct=1

Nextcloud est une exception, et il faut la dire. hide_login_form masque le formulaire ; …/login?direct=1 y accède encore, et l'amont le documente comme voulu — c'est ainsi qu'un administrateur entre. La protection est donc de ne plus l'annoncer, pas de l'interdire. Le présenter comme équivalent à Grafana ou Forgejo donnerait un faux confort.

Le réglage s'appelle <rôle>_connexion_locale dans les trois rôles, et vaut false par défaut. Le passer à true rouvre la porte, explicitement.

Garde de version. ENABLE_INTERNAL_SIGNIN n'existe que depuis Forgejo v10 (suivi amont, ticket 7476 : « This option was added to Forgejo v10 »). Sur une version antérieure il serait ignoré sans erreur — le rôle croirait avoir fermé la porte. Un assert refuse donc connexion_locale: false sous 10.0.0 plutôt que de laisser croire.

4. La chaîne de secours

Trois maillons, aucun ne dépendant d'une porte web ouverte :

1. SSO            Keycloak → LDAP                     ← la voie normale
2. sudo via SSH   occ / grafana-cli / forgejo admin   ← Keycloak ou LDAP en panne
3. console Proxmox de la VM                           ← SSH inaccessible

Un accès de secours qu'on ne sait pas emprunter n'existe pas : les commandes exactes sont dans le tableau ci-dessus, et les mots de passe locaux vivent dans la voûte unique de l'instance.

5. Ce qui reste à faire

• Prometheus et Loki exposent une interface sans SSO. oauth2-proxy est déjà éprouvé devant Icinga Web 2 : le patron existe, il reste à l'appliquer.
• Aucune preuve ne garde cette directive. C'est le même risque que les intégrations universelles avant leur inversion : une règle qu'aucune garde ne vérifie finit par ne plus être vraie. Le remède symétrique serait qu'un rôle déclare sa position (web-sso / ldap-direct / sans-auth-humaine, plus son accès de secours) et qu'une preuve refuse une interface humaine sans SSO ni secours déclaré.