coulomb/key-cape
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add keycape check-config; reject duplicate clientIds
All checks were successful
Authentication acceptance / acceptance (push) Successful in 1m25s
Details
Authentication acceptance / provider-contract (push) Successful in 25s
Details
Build and Publish Container Image / build-and-push (push) Successful in 43s
Details

Browse source 
net-kingdom asked for a way to validate a rendered configuration before
keycape-client.py restarts KeyCape (oidc-browser-relying-party review R4).
check-config runs every startup check that needs no secret, key or upstream:
validation, registry build, global tokenLifetime, policy-store clients and,
with --env-names, the secretRef bindings. The report carries no values.

ValidateConfig now refuses a clientId registered twice. The registry is a
map, so a duplicate silently replaced the earlier registration.

Also records the owners' amended CCR-2026-0018 sequence in KEY-WP-0013.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 779409@bnt-lap001
Assistant-Session: c658ca06-19b5-468d-be64-2985dc20bfd3
This commit is contained in:
tegwick 2026-10-10 13:28:36 +02:00
parent 5bc4a366b0
commit c528daa5be
9 changed files with 267 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/operations.md
View file

@ -70,6 +70,18 @@ The signing key and all client registrations are read once at startup. Both are
changed by editing configuration and restarting; there is no reload signal and no
rotation service.
**Check a changed configuration before the restart.** KeyCape exits at startup on
a configuration it refuses, and with one replica that stops sign-in for every
client. `keycape check-config --config PATH [--env-names A,B] [--policy-store]`
runs every startup check that needs no secret value, signing key or upstream, and
prints a JSON report with no values in it. The checks cover validation (including
redirect URIs with `?` or `*`, and duplicate `clientId`s), building the client
registry, the global `tokenLifetime`, and the clients the policy store requires
when `--policy-store` is set. With `--env-names`, it also checks that every
`env:` secretRef is among the variables the Deployment provides. It exits non-zero
when the server would refuse to start. It does not check that the key file is
readable or that a secret is non-empty, because it never sees either.
**The key ID is the constant `key-1`.** Rotating the signing key while keeping
that identifier is a trap: a consumer caching JWKS by `kid` may keep the old key
and reject freshly issued tokens until its cache expires. Plan rotation as