Implement verified public registration flow
This commit is contained in:
parent
b7a57a50a4
commit
c36a09bded
12 changed files with 610 additions and 7 deletions
|
|
@ -49,6 +49,22 @@ slice added `RegistrationVerificationPort`, bound request/receipt/evidence
|
|||
types, and a fail-closed HTTP adapter with purpose checking and normalized
|
||||
mailbox evidence. Adapter tests and the full 123-test suite pass.
|
||||
|
||||
Second code slice adds explicit allow-listed anonymous endpoints:
|
||||
`POST /api/v1/public/registrations` returns only a generic 202 status, while
|
||||
`POST /api/v1/public/registrations/verify` consumes purpose-bound evidence and
|
||||
attaches the verified email factor. Persisted registration sessions bind the
|
||||
random applicant subject, canonical username, client, and tenant. Evidence
|
||||
mismatch fails closed, browser-supplied return URLs are ignored, and this
|
||||
transition creates neither a user nor an LLDAP identity. Full suite now passes
|
||||
125 tests with 3 environment-dependent skips.
|
||||
|
||||
Third code slice completes the verified happy path: create the local user,
|
||||
call identity-provisioner with deterministic registration idempotency and only
|
||||
the baseline `user` role, link the returned subject under the configured
|
||||
KeyCape issuer, and redirect only to an allow-listed HTTPS provider password
|
||||
setup origin. Full suite now passes 126 tests with 3 skips. Automated recovery
|
||||
after local completion/provider failure remains open before production enablement.
|
||||
|
||||
## T02 - Orchestrate provider identity creation
|
||||
|
||||
```task
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue