Learning outcomes
- Separate authentication events, authorization decisions, proxy activity, and application actions.
- Define identifiers that join evidence without copying credentials or protected content.
- Detect missing, delayed, duplicated, and contradictory evidence.
- State which facts Pomerium can provide and which facts require another system.
Operating objective
An investigator can reconstruct one protected action from the initiating subject through authentication, session use, authorization, proxying, and the application's final result. Each record states what its producer observed. No record claims an event that only another component can see.
Use four distinct evidence classes. Authentication evidence describes an identity event and authenticator. Authorization evidence describes normalized inputs, effective policy, decision, and reason. Proxy evidence describes the routed request and upstream response. Application evidence describes the final object, action, state change, and business result. Infrastructure and identity-provider records add issuer, network, device, and administrative changes.
Signals and evidence
Define a stable request or trace identifier that survives trusted hops. Join it to session, subject, actor, tenant, route, resource class, action, policy version, decision, reason, upstream, response, and application event identifiers. Record safe credential fingerprints only when needed. Never log bearer tokens, cookies, authorization headers, private keys, or full secrets.
Preserve event time, ingestion time, producer identity, schema version, environment, and clock quality. Monitor collection gaps, parse failures, clock skew, duplicate identifiers, unknown policy versions, missing application results, and disagreement between enforcement and application records.
An allow decision does not prove that the proxy forwarded the request. A successful proxy response does not prove the intended application object changed. An application event without gateway evidence can indicate a direct path, background task, or incomplete instrumentation.
Response and recovery
- Start from the protected resource, action, subject, and bounded time range.
- Preserve source records and record query time, filters, and access to evidence.
- Reconstruct authentication and session creation. Do not infer the human actor from an unverified claim alone.
- Find the exact authorization input, policy version, result, and reason.
- Find the corresponding routed request, upstream endpoint, response, and retry behavior.
- Ask the application for the final object action and state transition.
- Identify missing hops and compare them with known direct, asynchronous, and recovery paths.
- Contain compromised authority, correct instrumentation gaps, and repeat the reconstruction.
Design tradeoffs and residual risk
More fields improve investigation and increase privacy, cost, and exposure. Central correlation simplifies analysis and creates a high-value record. Short retention limits exposure and can remove evidence before an incident is detected. Set field and retention choices from explicit investigation questions.
Shared identifiers improve joins and can enable cross-context tracking. Keep them scoped and access-controlled. Tamper-evident storage can show later alteration but cannot prove that a compromised producer reported the truth.
Residual risk includes uninstrumented direct paths, lost events, compromised producers, application actions outside request scope, and asynchronous work that uses copied authority.
Pomerium boundary
Pomerium can provide documented access and authorization fields for requests that traverse it. It can show route-level authentication, policy decisions, and proxy results that its components observed. It cannot prove the identity provider's full authentication ceremony, the application's final object-level action, a direct request that bypassed Pomerium, or an external side effect. Join Pomerium evidence with identity-provider, infrastructure, and application records.
Exercise
Perform one allowed and one denied administrative action. Use the request identifier to join identity-provider, Pomerium authorization, Pomerium access, and application records. Write a timeline that labels observed facts, inferred facts, and missing facts.
Then remove one application event and send one request directly to the origin in a controlled environment. Verify that the investigation detects both the evidence gap and the bypass instead of reporting a complete normal path.
Evaluation checklist
- Are authentication, authorization, proxy, and application events distinct?
- Can one request be joined across trusted components without logging a credential?
- Does each record identify its producer, schema, event time, and ingestion time?
- Can the system detect gaps, skew, duplicates, contradictions, and bypass paths?
- Does the investigation distinguish observed facts from inference?
Next learning unit
Authorization Decision Log
Record enough structured evidence to explain and test an access decision without storing credentials or excess personal data.
