verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.

make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.

74 documents lus un par un. 66 corriges, 8 exacts.

CE QUI ETAIT FRANCHEMENT FAUX

AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.

courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.

DES MODELES DECRITS D APRES UN MONDE ANTERIEUR

Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.

CE QUI CASSE AU PREMIER ESSAI

Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.

DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME

P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.

Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.

CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT

Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.

make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

2026-09-06 16:18:23 -04:00

5.3 KiB

Raw Blame History

Identité & SSO

Unité d'apprentissage — une lentille sur un fondamental des TIC. Moule : ① le concept → ② comment Set-OPS le fait → ③ pourquoi c'est transférable → ④ à toi de jouer.

① Le concept (générique)

Authentification vs autorisation — deux questions distinctes, souvent confondues :

Authentifier = qui es-tu ? (prouver son identité, ex. mot de passe).
Autoriser = as-tu le droit ? (permissions une fois identifié).

L'annuaire = la source de vérité des identités. Un seul endroit où existent les comptes ; tout le reste s'y réfère. Une identité, un mot de passe — partout.

SSO (Single Sign-On) = une authentification donne accès à N services, sans se reconnecter à chacun.

OIDC / OAuth2 = le protocole standard du SSO web. L'application ne voit jamais ton mot de passe : elle délègue la connexion à un fournisseur d'identité (IdP), qui lui renvoie un jeton signé prouvant qui tu es.

Fédération = un système d'identité en délègue un autre (ex. l'IdP lit les comptes depuis l'annuaire, sans les recopier).

② Comment Set-OPS le fait (le vrai, dans le lab)

Trois pièces, un rôle chacun :

Pièce	Rôle	Concept incarné
OpenLDAP (`serveur_openldap`)	l'annuaire — la source de vérité. `testmail` y vit.	annuaire
Keycloak (`serveur_keycloak`)	le fournisseur d'identité (IdP) SSO. Il fédère OpenLDAP en mode `WRITABLE` : il écrit à travers, vers l'annuaire.	SSO, OIDC, fédération
oauth2-proxy (`serveur_oauth2_proxy`)	une passerelle OIDC pour les apps sans OIDC natif.	motif proxy d'authentification

Les applications se branchent de deux façons :

OIDC natif — Grafana, Forgejo → bouton « Se connecter avec Chezlepro ».
Sans OIDC — Icinga Web 2 → placé derrière oauth2-proxy, qui fait l'OIDC à sa place.

Le flux, quand testmail ouvre Grafana :

Navigateur ──> Grafana : "connecte-moi"
Grafana   ──> redirige vers Keycloak (IdP)
Keycloak  ──> demande le mot de passe ; le VÉRIFIE contre OpenLDAP (fédération)
Keycloak  ──> renvoie au navigateur un CODE
Navigateur──> Grafana échange le code contre un JETON signé
Grafana   ──> crée la session : "tu es testmail" ✔

Résultat : une identité (testmail, un seul mot de passe LDAP) ouvre le courriel, Grafana, Forgejo et Icinga. Change le mot de passe une fois, il change partout.

Pourquoi WRITABLE et pas « lecture seule ». Cette unité a écrit « lecture seule » jusqu'au 2026-09-06 ; ce serait plus prudent en apparence, et c'est un cul-de-sac. En READ_ONLY, un changement de mot de passe échoue sur « Federated storage is not writable » — or l'annuaire exige ce changement à la première connexion : la reprise du sysadmin butait dessus (constaté le 2026-08-07). Et UNSYNCED serait pire : Keycloak écrirait dans sa base, Dovecot et Postfix continueraient de valider l'ancien depuis LDAP — une identité, deux mots de passe, exactement ce que la doctrine interdit. WRITABLE écrit à travers : l'annuaire reste la source unique, Keycloak n'en est qu'un client.

③ Pourquoi c'est transférable

Tu n'as pas appris « Keycloak ». Tu as appris l'annuaire + OIDC + la fédération + le motif passerelle. Le même schéma existe partout :

Set-OPS	Équivalents ailleurs
OpenLDAP	Active Directory · FreeIPA · 389-DS
Keycloak	Entra ID (ex-Azure AD) · Okta · Authentik · Zitadel
oauth2-proxy	tout reverse-proxy OIDC (Traefik ForwardAuth, Pomerium…)
Fédération LDAP→IdP	AD → ADFS/Entra ; annuaire → n'importe quel IdP

Change les produits, le schéma reste. C'est ça, un savoir générique.

④ À toi de jouer

Prérequis : accès au lab (VPN), /etc/hosts pointant les services sur l'edge.

Vis le SSO. Ouvre https://grafana.chezlepro.internal → « Se connecter avec Chezlepro » → testmail. Puis ouvre Forgejo, puis Icinga : tu n'es reconnecté nulle part.
Observe le flux. Rouvre Grafana en navigation privée, ouvre les outils dév (F12 → Réseau) : repère la redirection vers Keycloak, puis le retour avec un code=. C'est ① en action.
Interroge l'annuaire (la source de vérité). Sur un nœud avec ldap-utils :
```
ldapsearch -x -H ldaps://idm-01.chezlepro.internal \
  -b ou=people,dc=chezlepro,dc=internal '(uid=testmail)'
```
Tu vois l'entrée que Keycloak fédère — il ne l'a pas recopiée.
Casse & répare (la fédération). Dans la console admin Keycloak → User Federation → désactive le fournisseur LDAP. Reconnecte-toi : échec (l'IdP ne voit plus l'annuaire). Réactive : ça remarche. Tu viens de sentir la dépendance requise entre l'IdP et l'annuaire.

Pour aller plus loin (référence technique — dépôt)

Rôles : roles/serveur_openldap, roles/serveur_keycloak, roles/serveur_oauth2_proxy.
Passerelle générique : roles/serveur_oauth2_proxy/ (README) — placer du SSO devant toute app.
Thème de connexion (identité Alliance) : roles/serveur_keycloak/files/themes/alliance-boreale/.
Concept de liaison requise (IdP ⟶ annuaire) : docs/bindings-conception.md §11.

5.3 KiB Raw Blame History