skip to content

When an identity provider authenticates its users against an upstream identity provider, which role does it play on each leg?

level: seniorimportance: nice to knowfreq 24%

answer

  1. one party, two legs, two roles
  2. consumer upstream, issuer downstream
  3. it re-asserts on its own authority
  4. downstream trusts the proxy's key only
  5. ProxyRestriction Count zero forbids re-assertion

basics

~20 s

It plays both. Toward the upstream party it is a service provider: it consumes and validates that assertion. Toward the downstream party it is an identity provider, issuing its own assertion under its own key and its own entityID.

solid answer

~50 s

A proxying party is a service provider on one leg and an identity provider on the other, and it must do both jobs properly. Upstream, it sends a sign-on message, receives an assertion and **validates** it like any consumer. Downstream, it issues a **new** assertion, signed with its own key and naming its own `entityID` as issuer — the downstream party trusts the proxy, not the upstream party it has never registered. That is the design's value and its cost: downstream parties integrate once, but they can no longer see who actually authenticated the person, and the proxy becomes the party whose key speaks for both legs. An upstream assertion may also carry `<ProxyRestriction>` in its conditions, which limits whether the receiving party may issue further assertions on the basis of it — `Count="0"` means it may not.

code

xml · 5 lines
xml
<saml:Conditions xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                 NotBefore="2026-09-19T09:00:00Z"
                 NotOnOrAfter="2026-09-19T09:10:00Z">
  <saml:ProxyRestriction Count="0"/>
</saml:Conditions>

go deeper

for a junior

Hold on to the shape: one party can be the consumer in one exchange and the issuer in the next, and the roles are decided per message rather than per deployment.

for a middle

Explain that the proxy issues a new statement under its own key rather than forwarding, and say what the downstream party therefore can and cannot see about the original sign-on.

for a senior

Bring out the operational consequences: attribute drift through the middle, a broken audit trail across the two legs, and the fact that lax validation at the proxy is lax validation for everyone behind it.

for a principal

Decide whether to own a proxy at all. It buys one integration per application and costs you a key that speaks for the whole estate, plus the mapping policy and the incident-time correlation that key implies.

## Two legs, two roles A proxying identity provider sits between two exchanges and holds a different role in each. - **Upstream leg — it is a service provider.** It sends a sign-on message to the upstream identity provider, receives an assertion in reply, and validates it exactly as any consuming party must: right issuer key, addressed to it, still current. - **Downstream leg — it is an identity provider.** It then issues its **own** assertion about the person, signed with its own key, naming its own `entityID` as the issuer, and addressed to the downstream party that asked. The second assertion is a new statement, not a forwarded one. That is the point people miss: a proxy is not a relay. It is a party that consumes a statement and then, on its own authority, makes one. ## What the downstream party sees The downstream service provider has registered exactly one counterparty — the proxy — and trusts one key. It normally has no registration for the upstream party at all, and may not know it exists. | Question | Answer at the downstream party | |---|---| | Whose key verifies the assertion it received? | the proxy's | | Whose `entityID` is named as issuer? | the proxy's | | Which party actually authenticated the person? | not visible from the assertion alone, unless the proxy chooses to convey it | | Who is accountable if the statement is wrong? | the proxy, because it is the party that made the statement | That last row is the honest summary of the arrangement: **the proxy re-asserts on its own authority**. It has substituted its judgment for the downstream party's, which is fine when everybody knows that is what was bought, and a governance problem when nobody does. ## ProxyRestriction An assertion's conditions can carry `<ProxyRestriction>`, which constrains re-assertion by whoever receives it. Its `Count` attribute states how many further indirections the asserting party permits between this assertion and one ultimately issued on the basis of it, so `Count="0"` means the receiving party must not issue a further assertion on the strength of this one. The element may also name the parties to which re-assertion is permitted. Two things follow: 1. an upstream party that does not want its authentication re-sold downstream has a way to say so in the assertion itself, rather than only in a contract; 2. a proxy that ignores it is not merely impolite — it is issuing statements the party it relied on explicitly declined to authorise. This is a condition on the assertion the proxy **received**. It says nothing about the shape of the new assertion the proxy issues, beyond whether issuing one at all is permitted. ## Why estates end up with a proxy - A hub that many downstream applications register with once, so that adding a partner is one integration rather than one per application. - Protocol translation, where the upstream and downstream halves of the estate arrived from different standards and one party absorbs the difference. - Policy enforcement in the middle: a party that adds an authentication step, filters which attributes travel on, or normalises identifiers across upstream parties that spell them differently. - A port community's shared gateway, where the terminal operator, the customs broker and the hauliers each authenticate at their own employer and meet at one consuming point. ## What it costs - **Attribute loss and drift.** Whatever the proxy does not carry forward is invisible downstream, and the mapping it applies becomes a second place where identity is decided. - **Concentration.** The proxy's signing key now speaks for every upstream party behind it, to every downstream party in front of it. It is the highest-value key in the estate. - **A blurred audit trail.** Downstream logs record the proxy as the issuer. Answering "who actually authenticated this person, and how?" needs correlation across both legs, which has to be designed in rather than discovered during an incident. - **Double validation duty.** The proxy must validate properly on the upstream leg, because nobody downstream can check what it accepted. A lax consumer in the middle is a lax consumer for everyone behind it. ## The check that catches most mistakes For any party in such a chain, ask of one message at a time: *am I consuming or asserting here?* A proxy answers "consuming" on one leg and "asserting" on the other, and needs the full duty of each. The failures are always a missing half — a proxy that validates the upstream assertion loosely because it trusts the partner, or one that re-asserts downstream without having been permitted to.

  • Does the proxy forward the upstream assertion, or issue a new one?
    It issues a new one. The downstream party has registered the proxy's `entityID` and key, so a document signed by an upstream party it has never heard of would fail validation. The proxy consumes upstream, decides what to carry forward, and makes its own statement under its own key.
  • What can a downstream party tell about which upstream party actually authenticated the person?
    Nothing from the assertion's issuer, which names the proxy. It sees what the proxy chose to convey — typically an attribute or an authentication context reference the proxy sets deliberately. If that information matters downstream, it is a design requirement on the proxy, not something the protocol supplies by default.
  • Why is the proxy's signing key the highest-value key in such an estate?
    Because every downstream party validates against it and none validates against anything upstream. Whoever holds it can make statements about any person on any upstream party's behalf, to every application in front of the proxy, and none of those applications has a second opinion to consult.

A freight forwarder accepts a booking from a shipper and then books with the carrier in its own name. The carrier's contract is with the forwarder, not the shipper — and a booking marked non-transferable is one the forwarder may not pass on at all.

saying these in an interview costs you the question

  • Describes the proxy as forwarding the upstream assertion unchanged.
  • Says the downstream party validates the upstream party's signature.
  • Thinks the proxy can skip validating upstream because it re-signs anyway.
  • Ignores ProxyRestriction because the assertion verified.
  • Assumes downstream logs show which upstream party authenticated the person.