In a SAML AuthnRequest, what do ForceAuthn and IsPassive each ask the identity provider to do?

## Two attributes, two different demands `<samlp:AuthnRequest>` is where the service provider states its terms before handing the reader over. Two of its attributes are about *how* the authentication should happen rather than *what* should come back. **`ForceAuthn`** is about freshness. Set to `"true"`, it asks the identity provider not to satisfy the request from a previous authentication of that person but to authenticate them again, now. The loan service uses it before a step that commits the institution to a cost: the reader may have signed in at nine in the morning, and the service provider wants proof that the person at the keyboard at four in the afternoon is still them. **`IsPassive`** is about visibility. Set to `"true"`, it asks the identity provider to answer without taking visible control of the user interface — no login page, no prompt, nothing the reader sees. The service provider is asking a question it does not want to interrupt anyone with: *if this browser already has an authenticated session with you, tell me who it is; otherwise say you cannot*. That is the silent-check pattern behind landing pages that greet a returning reader by name without ever pushing them through a login. ## When both are set The two pull in opposite directions: one asks for a fresh authentication, the other forbids showing anything, and a fresh authentication of a human usually requires showing something. The specification resolves it rather than leaving it to taste: when both are `"true"`, the identity provider must not freshly authenticate the presenter unless the constraint imposed by `IsPassive` can be met. Silence wins over freshness. In practice that combination is almost always a mistake in a service provider's configuration rather than a deliberate design. ## What comes back when it cannot comply A SAML `<samlp:Status>` carries a **top-level** `<samlp:StatusCode>` and may nest a **second-level** code inside it that refines the reason. A passive request the identity provider cannot satisfy comes back as a failure at the top level with `urn:oasis:names:tc:SAML:2.0:status:NoPassive` nested beneath it. Note what this is not: it is not an HTTP-layer error, and reading it requires parsing the response rather than looking at a transport status. Other second-level codes follow the same shape — `urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy`, for instance, when the identifier format the service provider demanded cannot be produced. The top-level codes are a small fixed set: - **`urn:oasis:names:tc:SAML:2.0:status:Success`** — the request was answered. - **`urn:oasis:names:tc:SAML:2.0:status:Requester`** — the failure is attributed to the sender of the request. - **`urn:oasis:names:tc:SAML:2.0:status:Responder`** — the failure is attributed to the responder, which is where a request it cannot satisfy lands. - **`urn:oasis:names:tc:SAML:2.0:status:VersionMismatch`** — the responder cannot process the request's version. The detail that decides whether a service provider handles any of this correctly is that the refinement is **nested inside** the top-level element rather than sitting beside it. ## The comparison | | `ForceAuthn="true"` | `IsPassive="true"` | |---|---|---| | Asks for | a fresh authentication event | an answer with nothing shown | | Typical use | step-up before a committing action | silent session check on arrival | | Guaranteed? | no — the identity provider decides | no — the identity provider decides | | Characteristic failure | none distinct; the service provider cannot tell from the request side | a nested `NoPassive` second-level status code | | When both are `"true"` | yields to the passive constraint | wins: nothing may be shown | ## The failure worth recognising A service provider adds a silent check on its landing page, sending `IsPassive="true"`. Readers with no session at the identity provider get a failure response, and the service provider's error handler — written for network faults — retries, or renders "single sign-on unavailable", or, worst of all, immediately starts another passive request. The reader sees a blank page cycling, nothing appears in the identity provider's authentication log because nobody authenticated, and the service provider's own log shows a stream of failures that look like an outage at the counterparty. The mechanism is mundane: a nested `NoPassive` means *there was no session to report*, which is a perfectly ordinary answer to a question that permits only silence. The correct handling is to stop being silent — fall back to a normal interactive login, or serve the anonymous version of the page — and never to loop. ## What an interviewer is checking That the candidate knows these are requests rather than switches, and that the service provider cannot verify from its own side what the identity provider actually did about `ForceAuthn`; only what comes back tells it anything. And that they can name the shape of the answer when compliance is impossible: a status with a second-level code, parsed out of the message, not a transport failure to be retried.