Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a09cbb-87c6-7900-a145-4ce53ba9f1a6
71 lines
4.8 KiB
Markdown
71 lines
4.8 KiB
Markdown
# Platform administrator acceptance
|
||
|
||
Priority workplan: USER-WP-0030. Platform administration requires the platform
|
||
operator role and MFA; policy changes and factor recovery require recent MFA. Membership in every tenant is not required. Ordinary tenant
|
||
administrators cannot read cross-tenant platform support records.
|
||
|
||
| Journey | Implemented acceptance | Remaining integrated evidence |
|
||
| --- | --- | --- |
|
||
| P01 Platform entry | Role-aware navigation and tenant-independent console; member denial | Existing provider sign-in acceptance still applies |
|
||
| P02 Tenant and first admin | Authority readback, local bootstrap rollback and retry without duplicate admin | Real first-admin sign-in depends on provider |
|
||
| P03 Tenant inspection | Exact identifier, ambiguous-name handling and selected scope | No new implementation gap |
|
||
| P04 Administrator recovery | Tenant restoration and recent-MFA lost-factor preview, proof attestation, signed scope confirmation, audited disable/readback/retry and replacement enrollment | Implemented and deployed; evidence: evidence/2026-09-13-p04-recovery.md |
|
||
| P05 Service operations | Checked provider/credential/mail status, controlled selected delivery and uncertain-outcome recovery | Deployed; see evidence/2026-09-13-p05-service-operations.md. Actual customer inbox receipt remains a user journey. |
|
||
| P06 Authentication policy | Recent-MFA scoped policy preview/apply/audit/rollback; mandatory and optional-after-enrollment; application MFA wins | Deployed and persisted; see evidence/2026-09-13-p06-authentication-policy.md. |
|
||
| P07 Tenant lifecycle | Authority version/confirmation, stale-state rejection and recovery | Application propagation must be verified at the application |
|
||
| P08 Support investigation | Exact reference across audit/delivery records, tenant filter, safe metadata, unknown-evidence state and delivery drill-down | Provider actions require provider evidence; portal records alone cannot prove rollback |
|
||
|
||
## Investigate a support reference
|
||
|
||
Open Platform activity from the platform navigation. Paste the exact support
|
||
reference and optionally the full tenant identifier. The view matches before
|
||
limiting display to the newest 100 records. It shows recorded actor/action and
|
||
current delivery state without raw payloads, free-text audit summaries, or provider
|
||
errors. Follow Inspect delivery to its retry/readback page. No matching records
|
||
means evidence is missing; it does not prove no action happened.
|
||
|
||
## Restore tenant access
|
||
|
||
Open the tenant's users page and choose Restore tenant account. Check the named
|
||
person and tenant in the confirmation. Verify the request through the established
|
||
support process. The operation restores that tenant account and prepares a missing
|
||
directory login. It does not reset a password, remove an authenticator, clear a
|
||
global suspension or prove account ownership. Use provider recovery for those
|
||
cases. Cancel makes no change; failed provider readback must not become local
|
||
success. Keep the support reference when escalating.
|
||
|
||
## Run acceptance
|
||
|
||
```sh
|
||
make test
|
||
make test-journeys JOURNEY_ARGS="--role platform_admin --report /tmp/platform-admin-report.json"
|
||
make test-browser-journeys
|
||
make test-journeys JOURNEY_ARGS="--role platform_admin --require-complete"
|
||
```
|
||
|
||
The platform completeness selection now includes P04–P06 and must pass with
|
||
`--require-complete`. The portal regression suite has 232 tests with disposable
|
||
PostgreSQL enabled; 30 isolated Chromium checks pass. Installed-provider native
|
||
and browser acceptance is recorded separately in P06 evidence. Customer sign-in
|
||
and application access remain USER-WP-0028 / KEY-WP-0034 / VERGABE-WP-0019.
|
||
|
||
## Historical provider handoff (superseded for P04–P06)
|
||
|
||
KEY-WP-0035/NK-WP-0033 and USER-WP-0030-T03 retain the provider gap. The registered
|
||
`net-kingdom-privacyidea-admin-token` route was rechecked and remains
|
||
non-resolvable: concrete custody path/fields, expiry/revocation and approved
|
||
attended action are unpublished. A provider credential for attended resolver
|
||
repair must not be assumed to be the correct ongoing realm-scoped factor-read
|
||
credential. The owner must establish the consumer contract and verify its exact
|
||
permissions and renewal before policy or recovery rollout. No secrets belong in
|
||
this document, support references, chat or activity records.
|
||
|
||
P04 recovery now uses the signed platform session and private provider service.
|
||
Use Authenticator recovery for exact-login preview and support-reference readback.
|
||
No provider credential or OpenBao login is requested from the operator.
|
||
See evidence/2026-09-13-p04-recovery.md for the implemented boundary and acceptance.
|
||
|
||
RPF-WP-0040 supplies the dedicated factor-read credential and renewal contract.
|
||
P05 verified its operating recovery; P06 deployed scoped policy and guarded
|
||
onboarding. The historical resolver-credential incident remains NK-WP-0033,
|
||
not a gate on the completed platform journeys.
|