Learning outcomes
- Separate signed assertions from unsigned convenience headers.
- Define an authenticated delivery path from proxy to upstream.
- Prevent clients and intermediate proxies from injecting identity.
- Test duplicate fields, direct origin, replay, key rotation, and fail-safe behavior.
Protection need
An upstream often receives identity in an HTTP field after a proxy authenticates the client. A client can send the same field unless the path removes or replaces it. Network location alone does not prove who created a header. The upstream needs an authenticated assertion or an authenticated intermediary boundary with strict field handling.
Security objectives and requirements
At the first trusted proxy, remove every client-supplied field in the identity namespace. Create one canonical signed assertion for the intended upstream. Protect the upstream connection with authenticated transport and private reachability. Configure intermediate proxies to preserve the assertion without merging duplicate fields. At the application, validate the assertion and reject ambiguity.
Treat unsigned claim headers as convenience data only when the same trusted path and signed assertion establish their integrity.
Security invariants and evidence
- Untrusted clients cannot choose or append an effective identity field.
- The application can authenticate the assertion issuer and intended audience.
- The origin rejects direct requests that did not use the trusted path.
- Duplicate or malformed identity fields produce a denial.
- Evidence identifies the client request, proxy decision, assertion, and application result without storing the bearer value.
Failure cases
- The origin is public and accepts a copied identity header.
- Two intermediaries append the same header and the application picks the attacker value.
- A load balancer preserves a client field before the identity proxy runs.
- The application decodes a token without verifying its signature or audience.
- Verification fails and the application falls back to an unsigned email field.
- A valid assertion for one route is replayed to another upstream.
Design tradeoffs and residual risk
Signed assertions improve origin verification but add key, clock, and validation dependencies. Mutual transport authentication protects the channel but not a compromised proxy. Private origins reduce exposure but internal callers can still spoof fields. Keeping both signed and unsigned forms helps legacy applications but increases ambiguity.
Use one canonical security input. Fail closed when it is invalid.
Pomerium boundary
Pomerium can replace client identity fields and send a signed JWT assertion plus selected headers to an upstream. Operators must restrict the upstream path. The application must validate the signed assertion and must not fall back to untrusted headers. Application authorization still follows identity validation.
Exercise
Send a request with a forged identity header through the normal route, then send it directly to the origin. Add duplicate mixed-case fields, an altered assertion, wrong audience, expired assertion, and unknown key. Confirm that no failure falls back to client identity.
Rotate the signing key and verify a controlled overlap and removal sequence.
Evaluation checklist
- Which component first removes untrusted identity fields?
- Can the origin authenticate both the proxy path and assertion issuer?
- Does the application reject duplicate, malformed, invalid, and wrong-audience inputs?
- Is there any fallback from failed signature validation to an unsigned field?
- Does a valid identity still receive separate object and action authorization?
Next learning unit
Gateway Bypass Path
Find every route that reaches a protected origin without the intended identity, policy, and evidence controls.
