net-kingdom/docs/verify-t06.md
tegwick 4e07d60ff1
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Validate cadence contract and require functional MFA verification
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06ea3-7939-7b63-8125-699f8b50bedd
2026-09-05 01:28:05 +02:00

2.9 KiB

Verify realm resolution and MFA

Exercise status: unexercised against a real or scratch privacyIDEA target; simulated HTTP failure matrix passed 2026-09-05 by codex.

Run bash sso-mfa/k8s/verify-t06.sh --user platform-root from the repository root in an attended terminal. Use an enrolled test user where possible. The script prompts for the current pi-admin password and, after lookup succeeds, a fresh TOTP/HOTP code including its token PIN if required. It never reads a bootstrap bundle or Kubernetes Secret. No password, OTP or token belongs in command arguments, logs or the receipt. Do not enable shell tracing.

--pi-url, --realm, and --resolver select a different approved target. The CLI requires HTTPS. The old positional secrets-directory argument is removed; repair-realm-live.sh now calls this interface and propagates failure.

Success requires all of these properties:

  • pi-admin authenticates and the named realm binds the expected resolver;
  • the resolver is LDAP and TIMEOUT, CACHE_TIMEOUT, and SIZELIMIT are present non-negative integers;
  • the exact username resolves through that resolver when queried by realm;
  • /validate/check succeeds and identifies a TOTP/HOTP token. Passthrough, static-password tokens, denied checks and missing token details fail.

Exit 0 means these properties passed; exit 1 means a failed phase; exit 2 means invalid usage or missing attendance. The sanitized JSON receipt carries only result, phase and proof names. A successful OTP validation consumes a code and may update token counters or authentication audit state. It does not create or repair configuration. This proves the privacyIDEA leg; complete KeyCape browser login, OIDC callback, enrollment and recovery remain separate exercises. Deployment diagnostics remain in verify-t04.sh and verify-t05.sh.

The response shapes follow the provider's realm API, user API, resolver API and validation API. If policy suppresses token details, the verifier cannot establish OTP proof and fails; do not weaken that check to accept passthrough.

Attended acceptance still required

On an approved scratch target, record the target revision and operator, retain the resolver tuning configuration privately, then clear each tuning field in turn. Run the verifier and retain each sanitized FAIL receipt. Restore the fields and run with a fresh OTP; retain the PASS receipt. Restore the target configuration even if any step fails. Do not break the production resolver to perform this test. The automated HTTP fixture demonstrates the same failure and restoration sequence but does not satisfy this attended exercise.