Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
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
107 lines
5.3 KiB
Markdown
107 lines
5.3 KiB
Markdown
# 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.
|
|
|
|
1. **Vis le SSO.** Ouvre `https://grafana.chezlepro.internal` → « *Se connecter avec
|
|
Chezlepro* » → `testmail`. Puis ouvre Forgejo, puis Icinga : **tu n'es reconnecté nulle part**.
|
|
2. **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.
|
|
3. **Interroge l'annuaire (la source de vérité).** Sur un nœud avec `ldap-utils` :
|
|
```bash
|
|
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.
|
|
4. **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.
|