# 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).*