Security Glossary

SAML Service Provider (SP)

The application or service that relies on an identity provider for user authentication in a SAML-based single sign-on system.

SAML Service Provider (SP) is the application that outsources authentication to an external Identity Provider. The SP publishes metadata (its entity ID, Assertion Consumer Service URL, and signing certificate), sends authentication requests, and consumes signed assertions to establish a local session.

SP Responsibilities

  • Generate authentication requests (SAMLRequest)
  • Receive responses at the Assertion Consumer Service (ACS) endpoint
  • Validate the assertion and map its NameID to a local account
  • Create and manage the local session

Assertion Validation

The core cryptographic and temporal checks (signature verification, NotBefore/NotOnOrAfter, Destination, InResponseTo, trusted issuer) are shared with the message and assertion. See SAMLResponse and SAML Assertion for that checklist. The concerns below are specific to acting as an SP.

ACS URL and Audience Binding

An assertion is issued for one specific SP. Two bindings enforce this, and both must be checked against this SP's own metadata, not against a value taken from the incoming message:

  • Audience: the assertion's <saml:Audience> must equal this SP's entity ID. An assertion legitimately minted for a different SP must be rejected, even if its signature is valid.
  • Recipient / Destination: the Recipient on the SubjectConfirmationData and the response Destination must match this SP's registered ACS URL.
<saml:AudienceRestriction>
  <saml:Audience>https://sp.example.com</saml:Audience>  <!-- must equal our entity ID -->
</saml:AudienceRestriction>
...
Recipient="https://sp.example.com/acs"                    <!-- must equal our ACS URL -->

Skipping the Audience check turns any SP the IdP serves into an oracle: an attacker who can obtain a valid assertion for a low-value SP can replay it to a high-value SP that trusts the same IdP.

Unsolicited (IdP-Initiated) Responses

An IdP-initiated response arrives at the ACS with no InResponseTo, because the SP never issued a request. This removes the strongest replay/CSRF defence, so an SP that accepts unsolicited responses cannot rely on InResponseTo at all:

  • Disable IdP-initiated login unless it is a business requirement.
  • If it must be supported, an absent InResponseTo is only acceptable when the flow was genuinely IdP-initiated; a present-but-unknown InResponseTo must always be rejected.
  • Fall back to short assertion lifetimes and one-time consumption of assertion IDs (track used IDs) to bound replay.

RelayState Handling

RelayState carries the SP's post-login return location back through the IdP round trip. Because it is reflected verbatim into a redirect after authentication, treating it as a trusted URL is an open redirect:

POST /saml/acs
SAMLResponse=PHNhbWxwOlJlc3BvbnNl...&RelayState=https://evil.example/phish
  • Only redirect to same-origin, allow-listed paths; reject absolute or off-site URLs.
  • Prefer an opaque server-side token (a key into a stored path) over a raw URL.

See Also