Add sso-diagnose.sh: verify all peertube-sso-incident claims into a log

- docs: record the open identity-forwarding question, auth contracts, and responsibility boundary
This commit is contained in:
Pontoporeia
2026-08-24 11:36:02 +02:00
parent f31addb6bc
commit e4b48867aa
7 changed files with 500 additions and 2 deletions
+2
View File
@@ -58,6 +58,8 @@
- [x] [Diagnosed & reproduced] Single LDAP credential (`xamxam@erg.be`). **Both** mail and PeerTube are now on `portail.erg.school` (LemonLDAP OIDC) SSO — verified: mail.erg.school advertises SMTP `XOAUTH2`/`OAUTHBEARER` after STARTTLS. The difference: mail kept `PLAIN`/`LOGIN` (additive migration) so the app's `PLAIN` auth still works; PeerTube *removed* the `password` grant (hard cutover) so `grant_type=password` → `invalid_grant`. Not fixable with any credential; needs admin to restore password grant, register OIDC client, or (best) set up `authorization_code`+`refresh_token`. Full report in docs/peertube-sso-incident.md.
- [x] Built `scripts/creds-test.sh` (gum UI) + `scripts/creds-probe.php` (PHP probe) + `just creds-test`, + public `PeerTubeService::probeAuth()` to isolate auth-vs-channel. Probes SMTP AUTH and PeerTube password grant with the stored creds; logs results (never the password). Added `probeAuth` to PeerTubeService.
- [x] Built `scripts/app-token.sh` (gum) + `just app-token` to test whether a long-lived PeerTube app token (client_credentials grant) is obtainable. Confirmed live: `client_credentials` is rejected for the built-in local client (unsupported_grant_type) → an admin must run PeerTube's create-client on the server first. OIDC presence not determinable anonymously.
- [x] Add `scripts/sso-diagnose.sh` (+ `just sso-diagnose`) to verify every claim in docs/peertube-sso-incident.md — DNS/rDNS, IdP discovery (grant types), PeerTube OAuth/password-grant, SMTP AUTH mechanisms, identity-header propagation — appended to `sso-diagnose.log` (never logs secrets). Fixed the identity-gap (❓): response headers cannot reveal the post-auth header LemonLDAP injects INTO the request; added a request-side echo probe (`--echo <url>` + `scripts/echo-headers.php`) to be hosted *behind* the same LemonLDAP vhost, plus a `server.REMOTE_USER` mirror.
- [x] Update docs/peertube-sso-incident.md with the open "❓" (what identity LemonLDAP forwards to PeerTube), the three possible post-migration auth contracts + copy-paste admin ask, an explicit responsibility boundary (no zero-blame), and the new `sso-diagnose.sh` / `echo-headers.php` tools.
- [ ] Consider decoupling PeerTube credentials from SMTP settings (separate peertube username/password fields in the admin) so mail SSO changes don't silently break uploads
- [ ] (Superseded) The earlier `client_credentials` app-token path is **ruled out**: idP `portail.erg.school` (LemonLDAP::NG OIDC) only supports `authorization_code` + `refresh_token`, no `password`/`client_credentials`/device flow. Real host is `portail.erg.school` (not `.be`). Topology: videos.erg.be (PeerTube, Belgacom ADSL), mail.erg.school (Mailcow), portail.erg.school (LemonLDAP SSO). No self-service OIDC client registration.
- [ ] Likely code change: PeerTubeService::obtainToken() switch to OIDC `authorization_code`+`refresh_token` against https://portail.erg.school/oauth2/token — requires admin to register an OIDC client + one-time interactive login to seed a refresh_token.