Set-OPS-Public/docs/conception/identite-sso.md

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/conception/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).