Daniel Allaire 2450c9ea65 observatoire : un seul nom pour la console, des deux cotes

grafana.chezlepro.internal et tableaux.genese.internal nommaient le meme
service de deux facons. Les deux deviennent observatoire.

Un nom de produit dans une URL se grave aussi dans les SAN du certificat et
dans les URI de redirection du SSO : remplacer Grafana obligerait alors a
renommer le service. Le nom dit desormais la fonction.

Le renommage a revele que les URI des clients Keycloak repetent a la main les
FQDN declares dans expose:. Rien ne les reliait. P66 garde ce lien, ecrite en
meme temps que le premier renommage.

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

2026-09-10 20:21:13 -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://observatoire.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