feat(kanidm): rename the portal oauth2 client to bitborg-web #406

Sammanfogat

supernaut sammanfogade 4 incheckningar från feat/rename-1b-oidc-client in i main

2026-08-10 05:45:37 +00:00

supernaut kommenterad

2026-08-09 21:12:04 +00:00

Ägare

ADR 0039 §1b, first of three identifiers. Renames the production portal OAuth2 client gitborg-web → bitborg-web.

Two sites, not one

The rename plan lists web_oidc_client_id as a single variable. It is actually duplicated:

group_vars/all/vars.yml — web_oidc_client_id, which feeds the portal's OIDC_CLIENT_ID and (via web_oidc_issuer) its OIDC_ISSUER
roles/kanidm/defaults/main.yml — a hardcoded - name: in kanidm_oauth2_clients, which is what Kanidm actually creates

Nothing derives one from the other. Moving only the first would leave the portal authenticating against a client id that does not exist — SSO fails closed, with no error until a user tries to sign in. Both are now cross-referenced in comments so the next reader cannot move one alone.

Mechanics

Same as the dev client in tranche 1. A client id is not renamable in place and kanidm-provision runs --no-auto-remove, so this declaration creates bitborg-web and leaves gitborg-web live. That is deliberate — the old client keeps serving until the orphan is deleted by hand, which keeps the cutover reversible until that final step.

The new client gets a fresh random basic secret (upstream has no API to set one), so vault_web_oidc_client_secret is re-vaulted from show-basic-secret and the web role re-applied.

Apply sequencing

Deliberately two applies rather than one, to shrink the outage:

--tags kanidm — creates the new client. Portal untouched, still using the old client and its existing secret. Zero user-visible impact.
Read the new basic secret, re-vault.
--tags web — one portal restart onto the new client id + secret.
Browser sign-in, then delete the orphan.

A single apply would have restarted the portal with the new id but the old secret, leaving SSO broken for the whole re-vault interval.

Dry-run note

site.yml --check reports failed=1 on the #275 OAuth2 scope-map drift gate: live=[] declared=[forgejo_users] for bitborg-web. This is a check-mode artefact, not a defect — scripts/apply-reconcile.py blind lists kanidm : Provision entitlement groups as ansible.builtin.command skipped in check mode, so the client is never created during a dry run and the later live-read sees nothing. Provisioning (tasks/main.yml:370) runs before the drift check (:541), so a real apply creates the client first. The pre-change baseline was failed=0 because the then-declared client existed live.

Baseline before this change was verified changed=0 on both hosts, so the single changed task in the dry run (Render the kanidm provisioning state) is attributable to this change alone.

Scope

Only identifier ① of §1b. The provision service account and the entry-manager group are untouched, so sign-up provisioning and signup:drill are unaffected. Also corrects four comments the rename makes untrue; the drift-measurement table at defaults:370 is deliberately left, since it records a live reading taken at a point in time.

ADR 0039 §1b, first of three identifiers. Renames the production portal OAuth2 client `gitborg-web` → `bitborg-web`. ## Two sites, not one The rename plan lists `web_oidc_client_id` as a single variable. It is actually **duplicated**: - `group_vars/all/vars.yml` — `web_oidc_client_id`, which feeds the portal's `OIDC_CLIENT_ID` and (via `web_oidc_issuer`) its `OIDC_ISSUER` - `roles/kanidm/defaults/main.yml` — a hardcoded `- name:` in `kanidm_oauth2_clients`, which is what Kanidm actually creates Nothing derives one from the other. Moving only the first would leave the portal authenticating against a client id that does not exist — SSO fails closed, with no error until a user tries to sign in. Both are now cross-referenced in comments so the next reader cannot move one alone. ## Mechanics Same as the dev client in tranche 1. A client id is not renamable in place and kanidm-provision runs `--no-auto-remove`, so this declaration **creates** `bitborg-web` and leaves `gitborg-web` live. That is deliberate — the old client keeps serving until the orphan is deleted by hand, which keeps the cutover reversible until that final step. The new client gets a fresh random basic secret (upstream has no API to set one), so `vault_web_oidc_client_secret` is re-vaulted from `show-basic-secret` and the web role re-applied. ## Apply sequencing Deliberately **two** applies rather than one, to shrink the outage: 1. `--tags kanidm` — creates the new client. Portal untouched, still using the old client and its existing secret. Zero user-visible impact. 2. Read the new basic secret, re-vault. 3. `--tags web` — one portal restart onto the new client id + secret. 4. Browser sign-in, then delete the orphan. A single apply would have restarted the portal with the new id but the old secret, leaving SSO broken for the whole re-vault interval. ## Dry-run note `site.yml --check` reports `failed=1` on the #275 OAuth2 scope-map drift gate: `live=[] declared=[forgejo_users]` for `bitborg-web`. This is a check-mode artefact, not a defect — `scripts/apply-reconcile.py blind` lists `kanidm : Provision entitlement groups` as `ansible.builtin.command skipped in check mode`, so the client is never created during a dry run and the later live-read sees nothing. Provisioning (tasks/main.yml:370) runs before the drift check (:541), so a real apply creates the client first. The pre-change baseline was `failed=0` because the then-declared client existed live. Baseline before this change was verified `changed=0` on both hosts, so the single `changed` task in the dry run (`Render the kanidm provisioning state`) is attributable to this change alone. ## Scope Only identifier ① of §1b. The provision service account and the entry-manager group are untouched, so sign-up provisioning and `signup:drill` are unaffected. Also corrects four comments the rename makes untrue; the drift-measurement table at `defaults:370` is deliberately left, since it records a live reading taken at a point in time.

supernaut lade till 1 incheckning

2026-08-09 21:12:04 +00:00

feat(kanidm): rename the portal oauth2 client to bitborg-web

ci / ci (pull_request) Successful in 1m40s

Detaljer

258ce692e8

supernaut lade till 1 incheckning

2026-08-09 21:18:27 +00:00

docs(runbook): update the portal oauth2 bootstrap to bitborg-web

ci / ci (pull_request) Successful in 1m39s

Detaljer

8915689619