Axum applies layers outermost-first. With the previous ordering
(`Extension(jwks_state)` first, `require_jwt_auth` last), the JWT
middleware ran before the Extension layer attached `JwksState` to
the request, so `request.extensions().get::<JwksState>()` always
returned None and the middleware silently passed through every
request as if Keycloak weren't configured.
Verified end-to-end against the local CERTifAI Keycloak realm:
- no token / bad token -> 401
- active / trial -> 200 read, write reaches handler
- frozen -> 200 read, 402 on writes
- archived -> 410 on every method
The bug was invisible to the unit + integration tests because they
construct the layer stack manually; only the live wiring exhibited it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Lays the platform-wide multi-tenancy infrastructure on top of the
existing Keycloak signature validation. JWTs now carry tenant_id,
tenant_slug, org_roles, products, plan, and tenant_status; the
middleware decodes them into a TenantContext and attaches it to the
request extensions. A TenantCtx Axum extractor exposes the context to
handlers, and a tenant_status middleware enforces the §5c lifecycle
(frozen tenants are 402 on writes; archived tenants are 410 on every
method).
A db::tenant_filter helper in compliance-core gives every future
collection a single grep-able pattern for tenant-scoped queries.
Per-collection wiring (adding tenant_id to each model + threading the
filter through every find/update/delete call) lands in a follow-up.
Tests: 6 inline unit tests for claims→context mapping, 2 for the
extractor, 6 integration tests for status middleware, 3 for db
filter.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sharang Parnerkar