Core Concepts

This page builds up the SAML 2.0 conceptual framework from bottom to top: roles → Assertion → Protocol → Binding → Profile → Metadata, along with NameID, RelayState, and XML signatures/encryption that thread throughout.

Roles

Each IdP and SP is identified by a globally unique Entity ID (typically a URI, such as https://sp.example.com/saml/metadata), which is included in the protocol message's <Issuer> element. The process of establishing trust between SP and IdP is fundamentally about mutually registering each other's Entity ID, endpoint URLs, and signing certificates (see Metadata below).

Assertion (Assertion)

An Assertion is an XML statement document issued by the IdP, serving as the true bearer of "identity fact" in the entire protocol. A typical Assertion contains:

• <Issuer>: The issuer (IdP's Entity ID);
• <Subject>: Regarding whom (including NameID and SubjectConfirmation);
• <Conditions>: Validity conditions (time window via NotBefore/NotOnOrAfter, audience restriction via <AudienceRestriction>);
• One or more Statement (declarations).

Three Statement types:

A minimal Assertion skeleton:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                ID="_a1b2c3d4" Version="2.0" IssueInstant="2026-07-03T08:30:00Z">
  <saml:Issuer>https://idp.example.org/saml/metadata</saml:Issuer>
  <!-- ds:Signature typically appears here -->
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      [email protected]
    </saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData Recipient="https://sp.example.com/saml/acs"
          NotOnOrAfter="2026-07-03T08:35:00Z" InResponseTo="_req001"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-07-03T08:29:30Z" NotOnOrAfter="2026-07-03T08:35:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com/saml/metadata</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-07-03T08:30:00Z" SessionIndex="_sess42">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="mail">
      <saml:AttributeValue>[email protected]</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Protocol (Protocol Messages)

The Core specification defines a set of request/response protocol messages (namespace urn:oasis:names:tc:SAML:2.0:protocol, commonly abbreviated samlp):

All protocol messages share a common set of attributes: ID (unique identifier used for replay prevention and InResponseTo correlation), Version="2.0", IssueInstant (issue time, UTC), Destination (receiving endpoint URL, which the receiver must validate matches their own).

Binding (Binding)

Binding specifies how protocol messages are carried over a concrete transport layer. Which Binding to use is determined by the endpoint declared in Metadata.

Profile (Profile)

A Profile combines Core messages and Binding into end-to-end interoperable use cases:

• Web Browser SSO Profile: The most core Profile, defining SP-initiated and IdP-initiated login flows involving a browser, including allowed Binding combinations and mandatory validation rules (such as bearer SubjectConfirmation's Recipient/NotOnOrAfter/InResponseTo validation).
• Single Logout Profile: Defines how logout messages propagate among the parties involved in a session.
• Others: Enhanced Client or Proxy (ECP, non-browser clients), Identity Provider Discovery, Assertion Query, etc.; less frequently used.

Detailed flows are expanded step-by-step in Typical Flows.

Metadata (Metadata)

The Metadata specification defines a standard XML format for entity configuration, with root element <EntityDescriptor> (namespace urn:oasis:names:tc:SAML:2.0:metadata), containing:

• entityID: Entity identifier;
• <IDPSSODescriptor> or <SPSSODescriptor>: Role descriptor, declaring supported Bindings and endpoints (such as IdP's <SingleSignOnService>, SP's <AssertionConsumerService>, both parties' <SingleLogoutService>);
• <KeyDescriptor use="signing|encryption">: Embedded X.509 certificate, declaring the signature verification public key and encryption public key;
• SP side can also declare policy switches like AuthnRequestsSigned, WantAssertionsSigned, etc.

Certificate exchange is the core of trust establishment: The SP obtains the IdP's signing certificate from IdP Metadata to verify Response/Assertion signatures; the IdP obtains the SP's certificate from SP Metadata to verify AuthnRequest signatures and encrypt Assertions. In practice, Metadata XML files or Metadata URLs are typically exchanged directly, avoiding manual entry errors.

NameID and NameID Format

<NameID> is the core element in an Assertion that identifies the subject; the Format attribute declares the semantics of its value. Common Formats:

The SP declares the desired Format in the <NameIDPolicy> of the AuthnRequest. The complete list is in the Reference Page.

RelayState

RelayState is an opaque parameter transmitted alongside the SAML message but not part of the SAML message itself (in Redirect Binding it's a query parameter; in POST Binding it's a form field). The specification limits its length to no more than 80 bytes.

• SP-initiated flow: The SP attaches RelayState when sending AuthnRequest; the IdP must echo it back unchanged. The SP typically uses it to record the "deep link the user wanted to access before login" and jumps there after successful login.
• IdP-initiated flow: RelayState is configured on the IdP side, typically filled with the target URL or an IdP-agreed identifier.

XML Signatures and Encryption

Where Signatures Appear

SAML uses XML-DSig enveloped signature (signature embedded within the signed element, <ds:Signature> immediately following <Issuer>), appearing at three levels:

1. Assertion signature: Signed on <saml:Assertion>, most important, nearly all IdPs enable it by default;
2. Response signature: Signed on the outer <samlp:Response>, can coexist with Assertion signature;
3. AuthnRequest / LogoutRequest signature: In POST Binding it's an XML signature; in Redirect Binding it is not an XML signature, but a detached signature of the string SAMLRequest=...&RelayState=...&SigAlg=..., placed in the Signature query parameter.

For signature algorithms, use rsa-sha256 or higher; reject rsa-sha1; likewise for digest.

What the SP Must Do When Verifying Signatures

1. Use the certificate registered in Metadata to verify signatures, not the embedded <ds:KeyInfo> certificate within the message (embedded certificates can only be used for key selection, not as trust anchors);
2. Confirm that the signature's Reference covers exactly the Assertion/Response element currently being processed (preventing XML Signature Wrapping attacks: attacker moves a legitimate signature node and inserts a forged node; the countermeasure is "first locate the signed element by ID, verify reference uniqueness, then read business data from that node," and use well-maintained SAML libraries rather than hand-written DOM processing);
3. If the configuration requires Assertion to be signed, an outer Response signature cannot substitute for the Assertion signature requirement, and vice versa; enforce according to local policy.

Encryption

Beyond signatures, the IdP can also encrypt the entire Assertion using the SP's encryption public key, producing <saml:EncryptedAssertion> (XML-Enc, typically RSA-OAEP wrapping an AES session key for hybrid encryption); similarly there are <EncryptedID> and <EncryptedAttribute>. Encryption addresses confidentiality of messages when passing through the browser (in POST Binding, Response lands in the browser). The transport layer must always be HTTPS; encryption is defense-in-depth on top of that. When Assertions contain sensitive attributes, enabling encryption is recommended.

Next: Read Typical Flows to see how these concepts form complete login/logout interactions, or directly consult Parameters and Message Reference.