Learning outcomes
- Distinguish identity-provider authentication, gateway route authorization, and application object and action authorization.
- Place each decision at the component that owns the required facts and protected resource.
- Trace denial, bypass, stale context, and evidence across all three decisions.
- Test that one successful decision cannot substitute for another.
System and boundaries
Model three controls:
- Authentication: An identity provider or verifier decides whether the claimant proved control of an authenticator for a subject account.
- Gateway route authorization: The gateway decides whether that authenticated subject may reach a named upstream route in the current context.
- Application permission: The application decides whether the subject may perform a business action on an exact object in its current state.
These controls protect different resources and use different facts. Authentication owns authenticators and identity-provider state. The gateway owns routes and request context. The application owns records, tenants, transactions, relationships, and business actions.
Request and decision flow
Trace one request from the browser to the identity provider, gateway, and application. For each decision, record the subject identifier, resource, action, context, policy, result, enforcement, cache, maximum age, and evidence.
An authenticated user can still receive a gateway denial. A gateway allow can still receive an application denial. A successful application read does not authorize a later update. Keep these results distinct in user feedback, telemetry, and tests.
Failure domains
- Authentication succeeds for the wrong linked account.
- The gateway allows a broad route that exposes an unprotected administrative endpoint.
- A direct network path bypasses the gateway.
- The application trusts a client-supplied identity header.
- The application treats route access as permission to every object.
- A stale group or object relationship preserves access after removal.
- Logs show the gateway allow but omit the application denial or action.
Design tradeoffs and residual risk
Central route policy improves consistency and reduces exposed paths. It cannot centralize facts that only the application understands. Repeating coarse policy at both layers can create drift. Sending more identity context helps the application decide but increases privacy and freshness risk.
Define one owner for each decision. Send only verified facts that the next owner needs. Correlate evidence without merging the policies into an ambiguous allow.
Pomerium boundary
Pomerium authenticates through an identity provider, establishes a Pomerium session, and enforces policy for an upstream route. It can pass a signed identity assertion to the upstream. The upstream application must validate the trusted delivery path and authorize its own objects and actions.
Exercise
Choose a finance application with list, view, edit, and approve actions. Draw the three decisions for one edit. Then test four cases: invalid authentication, valid identity with route denial, route allow with object denial, and full allow.
Add a direct-origin request and a changed object owner. Record which component denies each case and which event proves it.
Evaluation checklist
- Does each decision name a different protected resource and action?
- Does each control use facts from an authority it can trust?
- Can the application deny an action after the gateway permits the route?
- Can any path reach the application without the intended gateway control?
- Can evidence correlate all decisions without treating them as one result?
Next learning unit
Object and Action Authorization
Authorize every application action against the exact object instead of trusting route access, a role, or an object ID.
