Architecture

Three services, one explicit enforcement point

Identity authenticates the user, Policy evaluates a configured rule, and the API that owns the data enforces the decision. Neither Identity nor Policy automatically protects an application endpoint.

Identity validates the active session, Policy decides allow or deny, and your API enforces the decision.
1 · Identity

Verifies the bearer access token and checks the session is still active in PostgreSQL. It returns the authenticated user's ID and role.

2 · Policy

Accepts a server-authenticated evaluation request. It maps the verified role through the API principal's configured role-to-domain mapping and decides whether the target is allowed.

3 · Internal API

Returns protected data only after an explicit allow. A deny becomes 403; an unavailable or malformed upstream response becomes 503.

Trust boundaries

Data and policy

Identity persists accounts and revocable sessions in PostgreSQL. Password hashing, refresh rotation, and session revocation stay in Identity. Policy configuration defines clearance domains, compartments, trusted API principals, and optional role mappings. Policy changes can be checked with the policy validation command before restart.

The Rust/Diesel example is a read-only integration experiment against the Identity schema. It demonstrates typed queries but does not own authentication or become another source of truth.

Failure behavior

See the runnable quickstart, policy configuration, and security limitations.