tegwick
4e07d60ff1
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06ea3-7939-7b63-8125-699f8b50bedd
48 lines
2.9 KiB
Markdown
48 lines
2.9 KiB
Markdown
# 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](https://privacyidea.readthedocs.io/en/stable/modules/api/realm.html),
|
|
[user API](https://privacyidea.readthedocs.io/en/stable/modules/api/user.html),
|
|
[resolver API](https://privacyidea.readthedocs.io/en/stable/modules/api/resolver.html)
|
|
and [validation API](https://privacyidea.readthedocs.io/en/stable/modules/api/validate.html).
|
|
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.
|