What must a service provider check before it accepts a SAML response and logs the user in?

That the signature is valid with the trusted IdP's key and covers the assertion it uses, that the issuer, audience, recipient and InResponseTo match, that the assertion is within its validity window and has not been used before.

"Verify the assertion" is a checklist, and skipping any item opens a known attack:

1. Signature: verify the XML signature with the IdP certificate from trusted metadata, and make sure the signed element is the very assertion whose data you then read (otherwise: signature wrapping).
2. Issuer: is it an IdP you trust for this user?
3. Audience: is your own entity ID in <AudienceRestriction>? (Otherwise: assertions for another SP accepted.)
4. Recipient and Destination: was it meant for this assertion consumer endpoint?
5. InResponseTo: does it answer a request you actually sent in this browser session? (Otherwise: injected or unsolicited responses.)
6. Time: NotBefore / NotOnOrAfter with a small clock skew.
7. Replay: reject an assertion ID you have already consumed.
8. Authentication context: is the login strong enough for this resource?

Only then does the SP map the NameID and attributes to a local session. In practice, these checks are best left to a well-maintained SAML library rather than hand-written XML code.

Go deeper:

• OWASP SAML Security Cheat Sheet — the complete checklist with the attack behind each rule.
• OASIS: SAML V2.0 Profiles (PDF) — section 4.1.4 has the normative response processing rules.