SECURITYATLAS✳

✳ The reference desk / In practice

SAML

An XML assertion from an identity provider to a relying application. A signed authentication statement says the provider authenticated the subject. It does not, by itself, authorize every function in the application.

Security Assertion Markup Language

What it means

Security Assertion Markup Language (SAML) carries identity statements between configured parties. In Web Browser SSO, an identity provider supplies an authentication assertion for a service provider. The browser can deliver the response; the assertion is an object carried in that response, not another actor.

The service provider checks its configured trust, signatures, issuer, recipient, audience, time conditions, request correlation, and replay protections before accepting the statement. A signature alone does not make the assertion suitable for every application. Accepted identity information can map to a local account and a separate application session. Local policy still decides what that account may do.

The idea at a glance / Identity

A signed assertion is not a reusable login.

Compare first acceptance of one SAML assertion with its repeated presentation. Replay protection can refuse a still-valid signature without ending an existing local session.

id.chronos.orbital assertion A42 names subject p42 for Chronos Hub, recipient its ACS, and request Q42. At 09:02 UTC it is within 09:00–09:05. The first POST passes configured checks and creates WP7; the repeated POST finds A42 already used.

SAML: Compare first acceptance of one SAML assertion with its repeated presentation. Replay protection can refuse a still-valid signature without ending an existing local session. The explanation below describes the relationships.id.chronos.orbital → Chronos Hub09:02 UTC · first POST and repeated POSTA42 · subject p42 · chronos-hubSigned · valid 09:00–09:05 UTCChronos Hub ACS · request Q42First POST · local session WP7Configured checks pass · A42 unusedp42 → DP17 · A42 recorded as usedRepeat POST · no new sessionA42 already used · replay refusedSignature + time still valid · WP7 staysWP7 · local permission checksD8 read allowed · E99 export refusedOriginal records stay at Chronos HubASSERTION ≠ LOCAL SESSION

READ THE PICTURE

Read the separate scopes

Chronos Hub accepts A42 once and creates WP7 for DP17. Repeating A42 is refused while its signature and time remain valid; WP7 stays active. Separate WP7 requests allow assigned pad D8 and refuse export E99. A signed assertion does not grant every application action.

Keep in mindThis is a decoded check summary after browser delivery, not XML or a complete SAML login. Signature and protocol checks are assumed. Repeating an assertion and reusing a local session are different operations.

Read the complete example
  1. Read the separate scopes. Chronos Hub accepts A42 once and creates WP7 for DP17. Repeating A42 is refused while its signature and time remain valid; WP7 stays active. Separate WP7 requests allow assigned pad D8 and refuse export E99. A signed assertion does not grant every application action. This synthetic example uses SP-initiated SAML 2.0 Web Browser SSO with an HTTP-POST response. Before this comparison, Chronos Hub sent request Q42 through the browser to id.chronos.orbital, id.chronos.orbital authenticated subject p42 under its configured policy, and the browser delivered the response over verified HTTPS to Chronos Hub’s Assertion Consumer Service (ACS). A42 is a safe assertion identifier, not its XML or a bearer secret. The exact issuer is https://id.chronos.orbital, audience is chronos-hub, and Recipient is https://hub.chronos.orbital/saml/acs. InResponseTo is Q42. Its applicable time conditions allow 09:00 through before 09:05 UTC on the authored test day; processing is at 09:02. The first POST assumes all required response and assertion processing succeeds: configured issuer and trusted signing key, signature and allowed algorithms, destination and recipient, pending-request correlation, bearer subject confirmation, Conditions, audience, and time checks. A42 is not in the used-assertion cache. Chronos Hub maps (id.chronos.orbital, p42) to pre-provisioned account DP17, records the used assertion ID for its validity window, and creates its separate local session WP7. A controlled second POST of A42 occurs within the same valid window. The used-ID check refuses replay and creates no new session. The signature, issuer, audience, recipient, and time values have not changed; the completed Q42 request is no longer an outstanding request, so fresh request correlation is not claimed to pass. WP7 is not revoked by that refusal. Independent application-policy tests using WP7 return a copy of assigned pad D8 and refuse unapproved export E99 while retaining original records. Assertion acceptance does not override these local permissions. Assertion expiration and local-session expiration are separate; provider logout or account disable does not guarantee coordinated local logout. This figure assumes a maintained, correctly configured SAML implementation and does not execute cryptography, XML parsing, trust discovery, or other SAML bindings and profiles.

This is a decoded check summary after browser delivery, not XML or a complete SAML login. Signature and protocol checks are assumed. Repeating an assertion and reusing a local session are different operations.

Diagram references: OASIS SAML 2.0 Profiles: Web Browser SSO processing and replay · NIST SP 800-63C-4: separate relying-party sessions

AN ILLUSTRATIVE SCENARIO

One assertion, two POSTs, separate permissions

RiverID assertion A42 identifies p42 for DockPortal and request Q42. At 09:02, the first browser POST passes the configured SSO checks and creates session WP7 for account DP17. DockPortal records A42 as used. A repeated POST before 09:05 is refused despite the unchanged signature and valid time window; it creates no new session and does not revoke WP7. With WP7, assigned dock D8 can be read, while export E99 is refused.

Put it to work

  1. Name the identity provider, service provider, exact audience, recipient, request correlation, and local account mapping.
  2. Use a maintained SAML implementation to enforce all required protocol and signature checks. Retain used assertion IDs for the required validity window.
  3. Test first acceptance, repeated assertion presentation, wrong audience or recipient, and expiration. Separately test local permissions and session revocation.

How to check your work

Confirm that A42 creates one session and its repeat creates none. Verify that WP7 remains governed by its own lifetime and revocation rules. Confirm D8 read succeeds and E99 export returns no protected content.

Connect the ideas

  • Federation

    Trusting authentication assertions from an external identity provider instead of storing every password locally.

  • SSO

    A pattern where one authentication to an identity provider is reused across multiple applications.

  • Authentication

    The act of verifying a claimed identity with authenticators such as passwords, passkeys, or certificates.

  • Authorization

    The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.