Le mur
Vous venez de passer une heure à configurer votre authentification centralisée. Vos collègues se connectent à la forge avec leurs identifiants habituels, le bouton fonctionne, les comptes se créent tout seuls. Satisfaction légitime.
Puis quelqu’un tente son premier clone :
git clone https://forge.nordika.local/it/scripts.git
Username for 'https://forge.nordika.local': jdupont
Password for 'https://[email protected]':
Il saisit son mot de passe de domaine. Et selon votre configuration, soit ça échoue, soit — pire — ça fonctionne, et il vient d’enregistrer son mot de passe de domaine dans le gestionnaire d’identifiants de sa machine.
C’est le malentendu le plus coûteux de cette section. Il ne vient pas d’une erreur de configuration, mais d’une propriété fondamentale des protocoles en jeu.
Pourquoi deux chemins
Reprenez le schéma de la leçon 2.6. L’authentification OIDC repose sur des redirections HTTP et une interaction humaine dans un navigateur : l’utilisateur est envoyé chez l’IdP, y saisit son mot de passe, valide éventuellement un second facteur, puis revient.
Maintenant, posez-vous la question : comment git push ferait-il cela ?
Il n’a pas de navigateur. Il ne sait pas suivre une redirection vers une page de connexion. Il ne peut pas afficher un formulaire de double authentification. C’est un client non interactif qui ne connaît qu’une chose : l’authentification HTTP basique — un identifiant, un secret, dans un en-tête.
NAVIGATEUR CLIENT GIT / DOCKER / API
│ │
▼ ▼
Redirection vers l'IdP En-tête d'authentification
Saisie du mot de passe HTTP basique
Second facteur │
Retour avec un jeton signé │
│ │
▼ ▼
┌─────────────────────────────────────────────────────┐
│ FORGEJO │
└─────────────────────────────────────────────────────┘
Le SSO couvre la colonne de gauche. Rien d’autre.
Ce qui n’est pas couvert
La liste est plus longue qu’on ne le croit, et elle recouvre l’essentiel de ce que nous ferons dans les douze sections suivantes.
| Usage | Couvert par le SSO ? | Ce qu’il faut |
|---|---|---|
| Navigation dans l’interface web | ✅ | Rien de plus |
git clone, pull, push en HTTPS |
❌ | Un jeton d’accès |
| L’API REST | ❌ | Un jeton d’accès |
docker login sur le registre (§10) |
❌ | Un jeton d’accès |
| Git LFS | ❌ | Un jeton d’accès |
| Le runner d’intégration continue (§9) | ❌ | Un jeton d’enregistrement dédié |
| Le lanceur de GPO (§7) | ❌ | Un jeton en lecture seule, ou un dépôt public |
| Semaphore, Dockerhand et consorts (§12) | ❌ | Un jeton à portée limitée |
Autrement dit : le SSO règle la question du confort de connexion, pas celle de l’accès machine. Et comme cette formation consiste précisément à faire dialoguer des machines avec la forge, c’est le second sujet qui va nous occuper.