In SAML 2.0 web single sign-on, which party issues a SAML assertion and which party acts on it?

## Two parties, one job each SAML 2.0 web single sign-on is a conversation between two kinds of party, with the person's browser carrying the messages between them. The **identity provider** is the party that holds authentication state for the person. It operates a `<SingleSignOnService>` endpoint, authenticates the person there by whatever means it chooses, and **issues** a signed `<saml:Assertion>`: an XML statement that a subject authenticated at a given instant, usually carrying attributes about that subject as well. Signing is what makes the statement usable by somebody else — it is the only reason a second party has to believe a document that arrives through an untrusted browser. The **service provider** is the application the person actually wanted. It **consumes** the statement. It operates an `<AssertionConsumerService>` endpoint, receives the assertion there, validates it, and creates its own local application session for the person. In this exchange it handles no password, no one-time code and no authenticator; it handles a signed document about somebody who proved themselves elsewhere. Each party is named by an **`entityID`** — a stable identifier for the organisation or deployment, not for a person. `entityID` is how the messages refer to the parties, and how each side looks up what it already knows about the other. ## Which endpoint belongs to which role | Role | Endpoint it operates | What it does | What it does not do | |---|---|---|---| | Identity provider | `<SingleSignOnService>` | authenticates the person, issues and signs the assertion | it does not run the application, and it does not decide what the person may do there | | Service provider | `<AssertionConsumerService>` | receives the assertion, validates it, starts a local session | it does not check credentials in this exchange, and it does not sign anything for the other side | | Attribute authority | described by `<AttributeAuthorityDescriptor>` | answers queries for attributes about a subject | it authenticates nobody and issues no authentication statement | The attribute authority is the third role the standard defines, and it is worth knowing because it is the counter-example that makes the other two precise: a party can make statements about a subject without ever having authenticated that subject. ## Why the application sends you somewhere else The redirect that surprises first-time readers is the whole point of the design: - credentials, password policy and any additional authentication factor live in **one** place, so they can be changed once; - the application stores no password, so a breach of the application does not leak one; - when somebody leaves, disabling them at the identity provider stops new sign-ons everywhere, without touching each application; - an application acquired through a business-to-business deal can be added to the estate without provisioning a second credential for every person. The cost sits on the same axis. Concentrating authentication concentrates failure: if the identity provider is unreachable nobody signs in anywhere, and its signing key speaks for every application that trusts it. That is a real trade-off, not a footnote. ## Trust does not remove the duty to validate The most common misreading of the role split is that a trusted issuer makes validation ceremonial. It does not. "The identity provider is trusted" is a statement about a **key**, not about whatever arrives at an endpoint. The assertion consumer service is reachable from the public internet, the browser is a hostile transport, and any party can post XML to it. Validation is how the consuming side establishes that this particular document came from the party it trusts, is addressed to it, and is still current. A consumer that skips it because the issuer is trusted has moved a security decision to a party that never made it. The mirror-image error sits on the issuing side: an identity provider that delivers a signed assertion to whatever location a request nominates has turned itself into a delivery service for credentials aimed at somebody else. ## Where the roles get swapped in practice Consider a port community: a carrier, a terminal operator and a customs broker all reading the same consignment documents, with one party authenticating the people and the rest accepting its word. The recurring failures are all role inversions: 1. the consuming side treats a TLS connection from the issuer's usual host as proof of who issued the statement — TLS authenticates a host, not a document; 2. the consuming side validates nothing because the issuer is trusted; 3. the issuing side posts to a delivery location it never established belonged to the party named in the message; 4. somebody reads `entityID` as if it named the person who signed in. ## One deployment can hold both roles The roles are per-exchange, not per-host. A single deployment can publish both an `<IDPSSODescriptor>` and an `<SPSSODescriptor>` under one `entityID`, consuming assertions from parties above it and issuing its own to parties below it. What must not blur is the duty: whichever direction a given message travels, the side receiving it still validates it.