Authentification & Identités

Le réseau repose sur une seule identité par personne, gérée par Kanidm 🡕. Cette page explique comment un service vérifie qui vous êtes, selon deux chemins d’intégration, et ce qui se passe entre le navigateur, la passerelle et Kanidm.

Deux façons de s’authentifier

Tout part de Kanidm, le fournisseur d’identité (IdP) du réseau. Un service s’y relie de deux manières, selon qu’il sait parler OIDC ou non.

Chemin	Pour quels services	Mécanisme
OIDC natif	Service qui sait parler OIDC (Forgejo, Immich, Grafana…)	Le service dialogue directement avec Kanidm
Reverse proxy authentifiant	Service sans auth (page d’accueil, site statique, UI nue)	`oauth2-proxy` + Caddy protègent le service en amont

Identités et groupes

Comptes et groupes sont provisionnés dans Kanidm depuis etc/config.yaml : un compte par personne, des groupes qui pilotent les accès. Le groupe users contient tous les comptes ; idm-admins et idm-devs sont les groupes spéciaux d’administration et de développement.

Chemin 1 : OIDC natif

Quand un service sait parler OIDC, DNF le relie automatiquement : Kanidm provisionne un client OAuth2 par service, le secret est géré par sops, et le service redirige lui-même vers Kanidm pour la connexion. Rien à configurer à la main.

C’est le chemin privilégié : le service connaît l’identité et les groupes de la personne, et peut appliquer ses propres rôles (admin, lecteur…).

Chemin 2 : reverse proxy authentifiant

Un service sans authentification (la page d’accueil, un site statique…) ne peut pas vérifier une identité. DNF place alors une mire de connexion Kanidm devant lui, au niveau du reverse proxy de la passerelle. Trois composants coopèrent :

Caddy : le reverse proxy de la passerelle. Avant de servir le contenu, il délègue la vérification (forward auth) à oauth2-proxy.
oauth2-proxy : un démon par passerelle (écoute en local), client OAuth2 de Kanidm. Il porte la session et conduit le flux de connexion.
Kanidm : émet la mire de connexion et le jeton d’identité.

Autorisation par groupe

Une fois la personne connectée, l’accès est filtré par groupe Kanidm. Caddy transmet à oauth2-proxy la liste des groupes autorisés ; sans appartenance, la réponse est 403 même authentifié.

Session et SSO

Après connexion, oauth2-proxy dépose un cookie de session valable sur tout le domaine de la zone (.maison.domain.tld). Tous les services protégés de la zone partagent donc la même session : on se connecte une fois. Les endpoints du flux (/oauth2/*) sont hébergés sur le FQDN de la page d’accueil de la zone, qui sert d’ancre commune.

Accès interne vs externe

La protection peut être limitée à l’extérieur : les clients internes (LAN privé et VPN tailnet) atteignent le service sans connexion, tandis que les accès depuis l’extérieur passent par la mire Kanidm. Pratique pour un portail ouvert à la maison mais protégé sur Internet.

Secrets et certificats

Le secret du client oauth2-proxy est partagé avec Kanidm via sops (un secret de session s’y ajoute).
Le flux n’introduit aucun nouveau nom d’hôte : il réutilise le FQDN de la page d’accueil, déjà couvert par un certificat TLS du réseau.