Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06ea3-7939-7b63-8125-699f8b50bedd
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, andSIZELIMITare present non-negative integers; - the exact username resolves through that resolver when queried by realm;
/validate/checksucceeds 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.