generated from coulomb/repo-seed
109 lines
3.1 KiB
Markdown
109 lines
3.1 KiB
Markdown
# Registration Scenario And Security Conformance
|
|
|
|
Status: implemented conformance slice
|
|
Date: 2026-06-15
|
|
Related workplan: USER-WP-0015
|
|
|
|
## Purpose
|
|
|
|
This slice turns the NetKingdom registration and onboarding roadmap into an
|
|
executable local conformance contract. It proves that the headless APIs and the
|
|
optional UI contract can complete the main registration journey, fail closed on
|
|
security negative paths, redact sensitive values, and exercise adapter seams
|
|
without production infrastructure.
|
|
|
|
## Scenario Matrix
|
|
|
|
The registration matrix is defined in `user_engine.testing.scenarios` as
|
|
`REGISTRATION_SCENARIO_MATRIX`.
|
|
|
|
It covers:
|
|
|
|
- self-registration;
|
|
- prepared account claim;
|
|
- privileged role requiring approval;
|
|
- eID-backed assurance;
|
|
- family invite;
|
|
- tenant admin invite;
|
|
- group access;
|
|
- denied cross-tenant claim.
|
|
|
|
The broader `SCENARIO_MATRIX` now also names registration/onboarding,
|
|
prepared-claim, group-access hat, denied cross-tenant claim, and UI workflow
|
|
coverage.
|
|
|
|
## End-To-End Conformance
|
|
|
|
`tests/test_registration_security_conformance.py` includes a full local flow:
|
|
|
|
```text
|
|
register application/catalog
|
|
prepare account with onboarding hint
|
|
complete email-backed registration
|
|
claim prepared account
|
|
select active hat
|
|
read claims projection and identity context
|
|
export access-control facts
|
|
render admin UI
|
|
assert onboarding event emission and redaction
|
|
```
|
|
|
|
This proves the path from registration through identity context, claims
|
|
enrichment, active access context, access fact export, onboarding, and UI
|
|
diagnostics.
|
|
|
|
## Security Negative Paths
|
|
|
|
The conformance suite exercises fail-closed behavior for:
|
|
|
|
- weak factor requirements;
|
|
- duplicate identity links;
|
|
- prepared-account hijack attempts;
|
|
- expired prepared claims;
|
|
- missing or cross-tenant context;
|
|
- privileged prepared roles requiring approval;
|
|
- stale approval through approval-required access profiles.
|
|
|
|
Denied prepared-account claim decisions leave audit evidence without creating
|
|
memberships for the attacker or emitting successful activation events.
|
|
|
|
## Redaction And Diagnostics
|
|
|
|
Conformance checks assert that these values do not leak through diagnostics,
|
|
events, or UI output:
|
|
|
|
- normalized factor values;
|
|
- email addresses used for prepared account matching;
|
|
- sensitive profile values;
|
|
- access profile claim/default values;
|
|
- proofing adapter secret input.
|
|
|
|
Sensitive profile values are redacted in runtime projections as
|
|
`<redacted>`.
|
|
|
|
## Adapter Conformance
|
|
|
|
The local adapter conformance path covers:
|
|
|
|
- factor verification adapter normalization;
|
|
- authorization harness request capture and obligations;
|
|
- access-control fact export;
|
|
- onboarding handoff lifecycle gaps and resume;
|
|
- audit record availability;
|
|
- outbox replay through pending events;
|
|
- in-memory durable-store rollback behavior in existing port tests.
|
|
|
|
No provider-specific IAM, eID, SMS, email, authorization-engine, notification,
|
|
or workflow infrastructure is required.
|
|
|
|
## Commands
|
|
|
|
```bash
|
|
make test
|
|
make test-conformance
|
|
```
|
|
|
|
The Makefile targets currently run the same standard-library test suite. They
|
|
remain separate entry points so CI can split unit, integration, scenario, and
|
|
conformance execution later.
|