KNELAgentIdentityProvisioning/skills/agent-provisioning/references/systems.md

Per-system SSO + API key details (verified 2026-09-07/08 unless noted)

GLPI (cmdb.knownelement.com) — SSO VERIFIED WORKING

• SSO: "Login with KNEL Cloud" = plugin route /plugins/singlesignon/front/callback.php/provider/1?remember=1 → Cloudron OIDC → auto-provision.
• The login page defaults to whichever tab was last toggled ("Use GLPI login form" / "Use Single Sign-on"); a hidden noAUTO=1 input forces the local form — irrelevant under Cloudron-only policy, useful to recognize.
• API: GLPI 11 is OAuth/token-based. The legacy REST at /apirest.php/initSession exists: password login is DISABLED (400); user_token auth exists but the tokens in creds/glpi / creds/mglpi are STALE (401 ERROR_GLPI_LOGIN_USER_TOKEN). The app token in creds/glpi password field IS accepted (used as App-Token header).
• Per-user API token: My account (self-service) after SSO provisioning. Pair with the app token: GET /apirest.php/initSession with headers App-Token: <app> + Authorization: user_token <user>.
• Local web login as glpi super-admin hits a 6-digit TOTP at /MFA/Prompt whose secret is not stored anywhere — do not rely on the admin UI; the SSO path makes it unnecessary.

Gitea (git.knownelement.com)

• SSO: /user/oauth2/cloudron (button "Sign in with …" on the login page).
• Standalone install behind nginx on the shared box — local accounts exist from the August batch; Cloudron-only policy means new identities use SSO and legacy ones migrate.
• API: tokens via POST /api/v1/users/<login>/tokens REQUIRE basic auth AS that user (admin tokens cannot mint for others; there is no /admin/users/<name>/tokens route; Sudo header needs a real site admin).
• Token auth against /api/v1/user: the JSON has login; admin-ness shows in site_admin (absent = not admin; do not misread null as false).
• KNOWN BROKEN (2026-09-07/08): receive-pack 500s during the box incident — RESOLVED after the 09-08 repair (pushes verified). If pushes 500 again, check the shared box first (see incident-log.md).

Discourse (community.turnsys.com)

• SSO: /auth/openid_connect — a bare GET returns 403 (CSRF-gated); that is NORMAL and means the route exists. Complete the flow from the login page button or with a session + CSRF token.
• The login page is an Ember SPA: server-rendered HTML shows no SSO markers, which fooled one audit (2026-09-07) into "no SSO" — wrong. Check routes, not page source.
• API: user API keys (User-Api-Key header) minted via the user-approval flow; admin Api-Key + Api-Username impersonation needs an admin key. The vault's creds/discourse NOTE says its keys are NOT admin (they are also not hex — do not assume key format). creds/vptechops-discourse holds a WORKING user key (user vptechopsvptechops) — #933's "dead key" note is wrong.

Redmine (projects.knownelement.com)

• SSO: "Continue with KNEL Cloud" button POSTs/GETs /oauth. KNOWN BROKEN: /oauth 302-bounces straight back to /login with no provider redirect — verified 2026-09-07 AND 2026-09-08 (IdP healthy both times), so it is a Redmine plugin configuration issue, NOT the IdP. Retest before relying on it; until fixed, Redmine accounts cannot be created via SSO.
• API keys: GET /users/current.json (session or basic auth) returns the user's api_key; X-Redmine-API-Key header for calls. Vault convention: the API key is stored in the item's password field.
• Admin surface: /users.json lists users (admin only — 403 otherwise). Every admin candidate tested in the vault so far is NON-admin (they are all the founder's personal accounts anyway — RESTRICTED).

Shared infrastructure hazard

Gitea, Redmine, Discourse, GLPI, the pwvault, and the my. vhost all run on ONE box (152.53.37.179 = mail.knownelement.com). Symptoms there cluster: when several systems misbehave at once, suspect the box (see incident-log.md), file/update one ticket, and do not burn hours debugging four clients.