Threat-model an identity-aware access path

The system to model

An identity-aware access path is a distributed security system. It includes more than a sign-in page and a proxy rule. A typical path contains a client, an identity provider, a session mechanism, a route, a policy decision point, a policy enforcement point, an upstream application, and an evidence pipeline. The application can also make its own authorization decisions after the gateway allows the request.

Threat-model the complete path. A component can work as designed while the system still fails. A correct policy does not help when traffic can reach the application around its enforcement point. A valid identity assertion does not prove that the user can edit a specific record. A detailed decision log does not prove that the application performed the allowed action.

Security Engineering treats security as complete-system work under adversarial conditions. NIST SP 800-160 Vol. 1 Rev. 1 connects protection needs to system requirements, architecture, verification, validation, and evidence. Use that system view for the access path.

Assets and security objectives

Start with what the path must protect. Do not start with a product diagram.

Common assets include:

• Application data and sensitive actions.
• The availability and integrity of the protected service.
• User, device, service, and workload identities.
• Session cookies, tokens, signing keys, and other credentials.
• Routes, policies, identity mappings, and configuration.
• Authorization decisions, access logs, and application audit records.
• Administrative interfaces that can change any of these items.

Turn each important asset into a testable security objective. For example:

• Only an authenticated employee in the on-call group can open the incident console.
• Only the incident owner can change the incident severity.
• A disabled account cannot start a new application request after the stated revocation limit.
• The upstream application accepts identity only from the approved enforcement path.
• An investigator can connect a policy decision to the application action that followed it.

The time limit and resource scope matter. "Authorized users can access the app" is not testable enough. Name the user class, resource, action, context, and time bound.

Actors and components

List human and non-human actors separately from the components that act for them.

• User or caller: The person, service, workload, or agent that wants access.
• Client: The browser, command-line client, desktop client, or service process that sends the request.
• Identity provider: The system that authenticates the user and supplies identity claims.
• Session authority: The component that creates, renews, and terminates the access session.
• Route selector: The mechanism that maps the external request to one protected upstream.
• Policy information sources: The identity directory, device posture service, risk service, and other sources that supply decision context.
• Policy decision point: The component that evaluates the request and policy.
• Policy enforcement point: The component that applies the decision and blocks or forwards the request.
• Upstream application: The protected service that receives an allowed request.
• Application authorization layer: The code or service that decides which records and operations the caller can use inside the application.
• Evidence pipeline: The logs, traces, policy versions, and application events used to reconstruct what happened.

One component can perform several roles. Keep the roles separate in the model. This makes missing checks and excessive authority easier to see.

Trust boundaries

A trust boundary is a place where one component must validate another component's identity, data, or authority before it continues. Draw each boundary even when both components run on the same network.

Mark at least these boundaries:

1. The client crosses into the public policy enforcement path.
2. The authentication flow crosses between the client, access system, and identity provider.
3. Session and identity data cross from the authentication role into later authorization decisions.
4. Request facts cross from the enforcement point to the decision point.
5. Policy and external context cross into the decision point.
6. The allowed request crosses from the enforcement point to the upstream application.
7. Identity context crosses into the application's own authorization layer.
8. Decision and application events cross into the evidence pipeline.

For every boundary, write four facts:

• Who sends the data?
• What identity and authority does the receiver expect?
• How does the receiver verify integrity, audience, freshness, and origin?
• What happens when verification fails or the required context is unavailable?

Transport Layer Security protects a channel. It does not by itself prove that a user can perform an application action. A signed token protects claims only when the receiver verifies the signature, issuer, audience, expiry, and other required context.

Normal request path

Trace one concrete request. Use a real host, route, method, resource, and user role. This example opens an incident record at https://incidents.example.com/incidents/482.

1. The client resolves the protected host and establishes a secure connection to the policy enforcement point.
2. The route selector matches the host and path to the incident application. An unmatched or ambiguous route fails closed.
3. If no valid session exists, the access system starts an authentication flow with the configured identity provider.
4. The identity provider authenticates the user. The access system validates the protocol response and establishes its own bounded session.
5. The enforcement point sends the subject, resource, action, route, and available context to the policy decision point.
6. The decision point gets the required identity, group, device, risk, and policy data. It returns an explicit allow or deny result.
7. The enforcement point applies that result. It forwards only an allowed request to the selected upstream.
8. The upstream verifies any identity assertion that it trusts. It rejects an invalid signature, issuer, audience, or expiry.
9. The application makes its own object and action decision. A gateway allow can establish that the caller may reach the incident application. The application still decides whether that caller may view or edit incident 482.
10. The policy system and application record enough linked evidence to reconstruct the request and outcome.

NIST SP 800-207 focuses zero trust on protected resources instead of network segments. It also separates authentication and authorization from network location. The request trace must therefore name the resource and decisions, not only the network path.

Failure path: direct upstream bypass

An attacker wins if the upstream accepts a second path that does not pass through the intended policy enforcement point. Common alternate paths include an internal load balancer, an old public address, a health port, an ingress default route, a service address reachable from another workload, or a direct administrative endpoint.

The bypass becomes more severe when the application trusts an unsigned identity header. A direct caller can set that header without passing authentication or policy. A signed assertion reduces this risk only if the application validates it and the assertion has the correct audience and lifetime.

Test the failure path:

1. Enumerate every address, listener, service, ingress, and route that can reach the upstream.
2. Try the same request from outside the approved enforcement path.
3. Confirm that network controls, mutual authentication, or application-layer assertion checks reject it.
4. Try to inject every trusted identity header directly.
5. Confirm that the application rejects the request or derives identity only from a verified assertion.

Do not record "the proxy is in front" as a control. Record the mechanism that prevents another path.

Failure path: stale identity and context

An authorization decision can use valid but obsolete data. A user leaves a group. A device becomes noncompliant. An account is disabled. A route policy changes. A cached decision or long-lived session can keep the old access effective.

Map the freshness chain for each decision input:

• Where does the fact originate?
• How does it reach the decision point?
• Which components cache it?
• What event refreshes or revokes it?
• What is the maximum stale interval during normal operation and during a partition?
• Does the system deny, use old data, or use a reduced policy when the source is unavailable?

Then test the stated bound. Start a valid session, remove the user's group or disable the account, and measure when a new protected request is denied. Repeat the test while a context source is unavailable. The result is a measured revocation limit, not a claim of continuous verification.

Failure path: split authorization

Gateway authorization and application authorization protect different resources.

The gateway usually has strong context about the caller, device, route, and connection. It can decide whether the caller may reach a named application or broad path. The application knows the object, business operation, current record state, ownership, and workflow. It can decide whether the caller may read record 482, approve a payment, or change another user's role.

Four combinations are possible:

1. Gateway deny, application unknown: The request must not reach the application.
2. Gateway allow, application deny: The caller can reach the service but cannot perform this operation.
3. Gateway allow, application allow: Both independent decisions approve the request.
4. Gateway bypass, application allow: The application becomes the only control. This is often the critical failure case.

Do not copy all object permissions into the gateway. Do not remove application authorization because the gateway authenticated the user. State which layer owns each decision and test both layers.

Decision and evidence model

For each security objective, connect the decision to evidence. A useful authorization record can include a correlation identifier, subject, acting service, route, resource class, action, policy version, relevant context versions, decision, reason, enforcement result, and timestamp. The application record can add the object identifier and business outcome.

Avoid logging session cookies, bearer tokens, full identity assertions, or unnecessary personal data. Evidence must be useful without becoming a second credential store.

Test evidence as a chain:

1. Start with one user-visible request.
2. Find the gateway access record.
3. Find the policy decision and reason.
4. Find the matching upstream or application event.
5. Confirm that the identifiers and times support one coherent account.
6. Confirm that a denied request has no successful application action.

Logs show what the instrumented components reported. They do not prove that an unmonitored bypass path does not exist.

Design tradeoffs and residual risk

Every placement choice changes the failure model.

• Central decisions and distributed enforcement: Central policy can improve consistency. It can also add latency, availability dependencies, and cache behavior that must be explicit.
• Fresh context and resilience: Short cache lifetimes reduce stale access. They can make a context service outage deny more traffic. Define the safe failure mode for each resource class.
• Gateway checks and application checks: Gateway checks reduce repeated integration work and stop unwanted traffic early. Application checks retain the object and business context that the gateway does not have.
• Signed identity and simple headers: Signed assertions let an upstream verify origin and audience. They add key distribution, rotation, time, and validation requirements. Unsigned headers are simpler but require a separately protected channel and strict removal of alternate paths.
• Detailed evidence and data minimization: More context can help an investigation. It also increases storage, access-control, and privacy exposure.

Record residual risk after controls. Examples include a short revocation delay, an unavailable device signal, an upstream that cannot validate assertions, or an emergency route with separate monitoring. Assign an owner and a review trigger. Do not hide the risk behind the word "trusted."

Pomerium boundary

Pomerium can provide the route-level policy decision and enforcement path for a protected application. Its documented architecture places the Proxy service between the client and upstream service and has the Authorization service evaluate policy for requests. The identity provider performs user authentication. Pomerium then manages its session and request context.

When identity headers are enabled, Pomerium can send a signed X-Pomerium-Jwt-Assertion to the upstream. The upstream must verify the signature, issuer, audience, and expiry before it trusts the claims. The application still owns object-level and action-level permissions that depend on its internal state.

Pomerium authorization and access logs can provide request and decision evidence. The operator must send those records to an evidence system with suitable retention and access controls. The application must produce its own events when the gateway record cannot show the final business action.

Pomerium cannot close an upstream path that the deployment leaves reachable around it. It cannot correct an inaccurate identity source or application permission model. The threat model must include those boundaries and controls.

Exercise

Choose one protected application and one sensitive action. Draw the normal request path from the client to the action. Add the identity provider, session authority, route selector, policy information sources, decision point, enforcement point, upstream, application authorization layer, and evidence pipeline.

Then add three attacker paths:

1. Reach the upstream without the enforcement point.
2. Keep access after a group, account, device, or policy change.
3. Use a gateway allow to perform an application action that should be denied.

For each path, state the control, failure behavior, test, evidence, residual risk, and owner. Run at least one negative test. Update the diagram when the observed path differs from the expected path.

Evaluation checklist

• Can you name the protected resource and action for every allow rule?
• Does every network and application path to the upstream cross an effective enforcement check?
• Can the upstream distinguish a verified identity assertion from a caller-supplied header?
• Is the maximum stale interval known for identity, group, device, policy, and session data?
• Does the application enforce object and action permissions after gateway access?
• Can an investigator connect one policy decision to one application outcome without using a credential as evidence?
• Does each dependency have a defined deny, degraded, or fail-open behavior?
• Have you tested at least one direct bypass, one stale-context case, and one application-level denial?