Daniel Allaire ac85278366 preuve : P34 — chaque document declare son lecteur (D-74)

La refonte de ce matin posait une convention. Une convention qu'on n'outille
pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique
au corpus documentaire.

Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32
autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus
utile du depot au §6 de autorisation.md.

Les 38 le declarent desormais, lecteur determine document par document et non
colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie,
gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur
externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE).

Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la
premiere page ajoutee : un document qui s'annonce genere, et un fragment sans
titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main
n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche
frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation
dans leur corps — d'etre exemptes a tort.

Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en
nommant deux documents que mon inventaire avait manques (docs/audit/). Puis
test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la
nommant ; restauree -> OK.

Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en
revue ; elle garantit qu'on a du y penser.

P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md
annoncaient encore 30 preuves).

Verifie : prouver.py 0 (34 OK), plan-recette inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-10 07:53:04 -04:00

3.1 KiB

Raw Blame History

Architecture d'identité et SSO

Pour qui : le mainteneur — les deux couches de l'identité, avant de brancher quoi que ce soit dessus.

Décision arrêtée (2026-07-02). Modèle A : OpenLDAP source de vérité, Keycloak fédéré pour le SSO web, mail en bind LDAP direct.

Principe : deux couches, pas deux choix

OpenLDAP = l'annuaire — source de vérité des identités (users, groups, mail, mot de passe). Standard, portable, compris par tout (mail, système, apps). On crée et gère les identités ici.
Keycloak = le cerveau SSO — OIDC/OAuth2/SAML : authentification unique des apps web, jetons, MFA, self-service, politiques. Fédéré à OpenLDAP (il lit l'annuaire, il ne le remplace pas).

              OpenLDAP  (source de vérité)
                 ▲                        ▲
     (fédération)│                        │ (bind direct)
              Keycloak                Dovecot / Postfix
          (SSO · OIDC · MFA)          (IMAP/SMTP auth)
                 ▲
      (redirection OIDC)
     ┌───────────┼────────────┐
  Forgejo     Grafana      Nextcloud …   ← apps web = SSO

Chemin d'auth par type de service

Type de service	Auth	Pourquoi
Apps web (Forgejo, Grafana, Nextcloud…)	Keycloak OIDC (SSO)	un seul login, MFA, jetons
Mail (Dovecot, Postfix)	LDAP direct (bind)	IMAP/SMTP ne parlent pas OIDC ; username + mot de passe
Système / services (SSSD, etc.)	LDAP direct	annuaire standard
Tout	→ même OpenLDAP	identité unifiée, aucun compte en double

Sens de provisionnement

Les identités se créent et se gèrent dans OpenLDAP. Keycloak fédère (lit LDAP en lecture ; écriture optionnelle pour le self-service). Aucune identité n'est « maître » dans Keycloak : c'est LDAP la référence. Le mail bind directement sur LDAP.

Pourquoi ce modèle (et pas Keycloak-source)

Mail-compatible : Dovecot/Postfix s'authentifient nativement contre LDAP ; contre Keycloak seul, c'est un casse-tête (OAuth2/XOAUTH2 pas universel côté clients).
Portable / souverain : l'annuaire reste un standard LDAP — chaque écosystème (tenant) a son OpenLDAP + son Keycloak fédéré, réplicable à l'identique. Sert directement la preuve de portabilité multi-tenant.
Séparation des responsabilités : LDAP = qui existe ; Keycloak = comment on se connecte au web. Chacun fait ce qu'il fait de mieux.

Conséquences pour Set-OPS

serveur_openldap (déployé) = le pilier annuaire, source de vérité.
serveur_keycloak = pilier SSO, à fédérer sur OpenLDAP (User Federation → LDAP).
serveur_dovecot / serveur_postfix = auth LDAP direct (cohérent avec ce modèle).
Les apps web déclarées dans le plan → clients OIDC de Keycloak.

Évolution possible (plus tard) : XOAUTH2 pour le mail via Keycloak, si les clients suivent. Ça n'est pas requis et ne change pas la source de vérité (LDAP).

3.1 KiB Raw Blame History