In SAML 2.0, what does a service provider give up by accepting unsolicited IdP-initiated responses?

## An unsolicited response is legal, not malformed The SAML 2.0 Web Browser SSO profile explicitly allows an identity provider to deliver a `<samlp:Response>` that no `<samlp:AuthnRequest>` asked for. A reader clicks the loan service in their institution's portal; the identity provider already has them authenticated; it produces a response and sends the browser to the service provider's assertion-consumer endpoint with it. Nothing is wrong with the message. Because there is no request identifier to quote, the response MUST NOT carry `InResponseTo`. So the question is never "is this valid SAML?" — it is "what does my service provider still know, and what has it stopped knowing?" ## What survives - The **signature** over the message or the assertion still establishes who produced it. - The **assertion** still names a subject, and its validity conditions still bound when and for whom it may be used. - The service provider still decides whether the sender is a party it trusts at all. An unsolicited login is not unauthenticated. It is uncorrelated, and those are different words. ## What is given up 1. **Correlation to a request.** With `InResponseTo` there is a question on file and the answer either matches it or is thrown away. Without one, any well-formed, correctly signed, still-valid response for a subject the service provider recognises is acceptable, whenever it is presented. Whoever holds such a response chooses the moment a session is created at the service provider — which is exactly the property a service provider that only supports SP-initiated login does not have. 2. **The state filed beside the request.** The deep link the reader was reaching for, the attribute set the service provider wanted, the tenant or connection it had already resolved — all of that was stored under the request `ID`. In the unsolicited case there is no key to retrieve it under and nothing was stored, so the service provider lands the reader on a default page or trusts a target the identity provider supplied. 3. **The ability to demand anything.** `<RequestedAuthnContext>`, `ForceAuthn`, `IsPassive`, `<NameIDPolicy>` and `AttributeConsumingServiceIndex` are attributes and elements of a request. With no request, the service provider takes the authentication the identity provider felt like performing, in the identifier format it felt like using. ## The switch, and where to put it | Policy | Rule at the assertion-consumer endpoint | Consequence | |---|---|---| | SP-initiated only | Reject any `<Response>` with no `InResponseTo` resolving to an outstanding request | Portal tiles at the counterparty stop working, and say so loudly | | Both directions | Branch on presence: match when present, apply unsolicited policy when absent | Correlation protects the SP-initiated half only | | Unsolicited, narrowed | Accept unsolicited only from named issuers, land on a fixed page, never follow a supplied target | Keeps the business case, removes the open-ended parts | The critical detail is that the branch must be on **presence**, not on lookup failure. "Look up the value; if nothing is found, treat the login as unsolicited" makes every failed match succeed, which is worse than not supporting the unsolicited direction and worse than not checking at all, because it looks like a check in code review. ## The loan service, concretely The inter-library loan service has one counterparty whose readers all arrive from a portal, and forty whose readers arrive by following citations. If it accepts unsolicited responses globally, the correlation check protects nobody: a response from any trusted issuer, for any subject, can be presented at any time. If it accepts them per counterparty, the forty keep the stronger path and the one gets the direction it needs. That per-counterparty decision is an integration policy; what this protocol layer gives you is the fact the decision turns on — the presence or absence of `InResponseTo`, and everything that presence was carrying. ## What an interviewer is listening for A candidate who says "IdP-initiated is less secure" has recited a slogan. A candidate who says "there is no request, so I have no state to match against, so I cannot refuse a login I did not start, and I lose the deep link and everything I would have asked for" has described the mechanism. The second answer also tends to arrive with the follow-up already handled: yes, the assertion is still signed; no, that is not the same property.