Trace an identity-aware application request

System and boundaries

Include the client, resolver, network path, TLS endpoint, identity provider, session service, route selector, policy information sources, decision point, enforcement point, upstream connection, application, object store, and evidence sinks. Mark which component terminates each authenticated channel and which identity applies after that termination.

Name two protected resources at minimum: the gateway route and the application object or action. They need separate authorization owners.

Request and decision flow

Trace these stages:

1. Resolve the external name and connect to the intended endpoint.
2. Establish TLS and validate the server identity.
3. Select the route from trusted scheme, authority, port, and path data.
4. Resume a valid session or authenticate through the identity provider.
5. Build the gateway authorization request with subject, route, action, and current context.
6. Decide and enforce route access.
7. Create a new authenticated channel to the intended upstream.
8. Remove untrusted identity fields and pass only verified identity context.
9. Let the application authorize its exact object and business action.
10. Return the response through the controlled path and record correlated evidence.

For every stage, record authority, input age, result, failure behavior, and correlation identifier.

Failure domains

• DNS or host confusion selects the wrong route or endpoint.
• A valid session carries obsolete identity or group state.
• A policy source fails and the route fails open.
• A direct origin bypasses the gateway.
• The gateway sends identity over an unauthenticated upstream connection.
• The application trusts a client-supplied header or skips object authorization.
• A long-lived connection outlasts a new denial.
• Logs cannot connect the route allow to the application action.

Design tradeoffs and residual risk

More per-request checks improve context freshness but add latency and dependency. More identity attributes improve policy precision but increase privacy and integrity risk. Central route policy reduces repeated controls but cannot own application object state. Long-lived connections improve efficiency but reduce reevaluation opportunities.

State the maximum acceptable stale window and failure result at each boundary.

Pomerium boundary

Pomerium can terminate the client connection, authenticate through an identity provider, select a configured route, enforce route policy, connect to an upstream, and pass verified identity context. The application remains responsible for its records, tenants, and business actions. Network owners must close paths that bypass Pomerium.

Exercise

Trace one employee request to edit a production record. Draw each component and authenticated channel. For every edge, record the identity, credential or assertion, resource, action, decision, cache, timeout, and evidence.

Test an invalid session, wrong host, route denial, direct origin, spoofed identity header, another tenant's object, changed object owner, and policy source outage.

Evaluation checklist

• Can the trace name every trust boundary and authenticated channel?
• Are authentication, route authorization, and object authorization separate?
• Does every path to the protected action pass through an intended enforcer?
• Are identity context, policy inputs, and decisions fresh enough for the action?
• Can evidence reconstruct the full request without exposing credentials?