Repository navigation
Armonia · Person identity: frontdoor authentication and verified principals #1874
Description
Important
Problem — Every access check today answers only "allowed or not" for a shared password, an open tunnel, or a machine's peer token. The frontdoor authenticates nothing, and no request carries who is calling, so nothing downstream can attribute, filter, or authorize by person.
Approach — The frontdoor authenticates each person against a deployment-local people registry and forwards a signed principal to the engines; the engine's authorization middleware verifies it and provides the principal to request handlers. Machine and peer credentials continue to authenticate machines, and resolve to machine principals.
Scope — in: people registry, person credentials (issue, revoke), frontdoor authentication, signed principal forwarding, engine-side verification, principal in request context, rejection of unauthenticated requests. out: SSO/OIDC, attribution of sessions (next slice), visibility filtering.
Assumptions — A deployment-local registry is acceptable for the first internal team; SSO can replace the credential source later without changing the principal contract.
Acceptance Criteria
- A request with no credential is rejected at the frontdoor, at the service runner, and at an engine reached directly.
- A request with a valid person credential reaches the handler with that person's principal available.
- A forged or unsigned principal sent directly to an engine is rejected.
- A revoked person credential is rejected on the next request without a restart.
- Existing machine and peer-token callers still succeed and resolve to a machine principal, not a person.
- The open-auth service mode is refused when the deployment is configured as a team deployment.
Testing Decisions
Extend the engine authorization middleware tests, the service runner authorization tests, and the frontdoor tests. Add a test that bypasses the frontdoor and presents a forged principal.
Key Decisions
- The frontdoor is the only component that accepts person credentials; engines accept only principals signed by the deployment's edge key.
- The principal is immutable for the lifetime of a credential.
- Machine credentials never resolve to a person.
Data Contracts
- Principal: id, kind (person | site | machine), display name, deployment id.
- People registry entry: person id, display name, credential hashes, revoked-at.
Constraints & Invariants
- No new routing authority; identity rides the existing edge-to-engine path (The connective tissue: one authority for location + liveness — the five-router architecture is one bug with many costumes #1760).
- Credentials are never logged and never stored in plaintext.
Prior Art
- The gateway-secret middleware, the engine authorization layer, the service runner's accept-set, and peer tokens (ADR 0032).
Activity
[-]Team engine · Person identity: frontdoor authentication and verified principals[/-][+]Armonia · Person identity: frontdoor authentication and verified principals[/+]