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
71 lines
3.8 KiB
Markdown
71 lines
3.8 KiB
Markdown
# 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 |
|
|
| **App web SANS OIDC natif** | **`oauth2-proxy` devant**, lui-même client OIDC | met au SSO ce qui ne sait pas y aller seul |
|
|
| Tout | → **même OpenLDAP** | identité unifiée, aucun compte en double |
|
|
|
|
> **L'ouverture de session Unix n'est PAS dans ce tableau, et c'est délibéré.** Cette ligne
|
|
> annonçait « Système / services (SSSD, etc.) → LDAP direct » jusqu'au 2026-09-06. Le dépôt
|
|
> ne fait pas ça : le rôle `client_ldap` a été **retiré le 2026-07-04, hors conception**, et
|
|
> aucun rôle n'installe SSSD. L'annuaire sert les **applications** ; l'accès à un hôte se
|
|
> fait par **clé SSH**, et l'élévation par `sudo`. Voir `docs/authentification.md` §2.
|
|
|
|
## 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éré sur OpenLDAP** — et la fédération est
|
|
*automatisée*, pas un geste manuel : `roles/serveur_keycloak/tasks/federation-ldap.yml`
|
|
(avec ses mappeurs d'attributs, ses groupes et sa politique de mot de passe dans les
|
|
tâches voisines). `make identite-plan` relit ensuite ce qui est réellement en place.
|
|
- `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).*
|