SAML Timing Brief
{{ summaryPrimary }}
{{ summaryLine }}
{{ summaryBand }} Fail {{ statusCounts.Fail }} Warn {{ statusCounts.Warn }} Pass {{ statusCounts.Pass }} {{ sourceFormatLabel }}
Name the SAML integration or ticket being reviewed.
Use the response captured at the service provider or the decoded assertion excerpt that contains timing attributes.
{{ sourceStatusLine }}
This is the relying-party clock used for NotBefore, NotOnOrAfter, and SessionNotOnOrAfter checks.
Use the verifier-side skew policy, commonly 60 to 300 seconds for SAML integrations.
seconds
Short assertion windows reduce replay exposure and make clock drift easier to isolate.
minutes
This catches bearer confirmation windows that outlive the intended replay boundary.
minutes
Use this only when your relying party expects bounded IdP session lifetime evidence.
hours
Warn when Conditions omit NotBefore
Most Web SSO assertions include both bounds; leave on for production review evidence.
Warn when IdP session expiry is absent
Use this only for integrations that intentionally consume IdP session lifetime signals.
{{ header }} Copy
{{ cell.text }} {{ cell.text }}
{{ emptyTableMessage(tab.key) }}
Tags: Encoding, Security
Export to PDF Fullscreen
Customize
Advanced
:

SAML bearer sign-in depends on short-lived XML assertions. The service provider has to decide whether the assertion is already usable, still usable, or outside the window that the identity provider intended. A clock that is a few minutes wrong, a validity interval that is too wide, or a missing bearer expiry can turn a normal single sign-on exchange into a replay or troubleshooting problem.

Timing review is useful when a SAML login fails with "not yet valid" or "expired" errors, when an identity provider change shortens or lengthens token lifetime, or when an incident note needs exact timestamps instead of guesses. The important comparison is not just the printed expiry value. It is the relationship between the relying-party reference time, the allowed clock skew, the assertion Conditions window, the bearer confirmation expiry, and any IdP session expiry.

SAML timing review timeline showing assertion, bearer confirmation, and session windows against a reference time.

Timing checks cannot prove that a SAML response is trustworthy. They do not validate the XML signature, issuer key, audience, recipient, destination, request binding, or replay cache. A timing pass means the timestamp evidence is usable under the chosen policy; the relying party still has to make the full trust decision.

The most common timing mistakes are small and concrete. A NotBefore value a few minutes ahead of the service provider can block fresh logins. A NotOnOrAfter value far in the future widens replay exposure. A bearer confirmation window that outlives the assertion Conditions window can make the delivery proof last longer than the assertion itself.

Technical Details:

SAML Conditions place time limits on an assertion. NotBefore names the first instant when the assertion may be accepted, and NotOnOrAfter names the instant at which the interval has ended. When both are present, the start must be earlier than the end. When either bound is absent, SAML Core treats that side of the interval as unspecified, which is why a production policy can warn about a missing bound even when the XML is still standards-compliant.

Bearer Web SSO adds a second time check on SubjectConfirmationData. For bearer delivery, NotOnOrAfter limits the window in which the assertion can be confirmed by the relying party, while Recipient and InResponseTo tie delivery to an endpoint and request. This timing review inspects the expiry value and its relationship to the assertion window; endpoint, request, and signature validation remain relying-party checks.

AuthnStatement timing is different from assertion validity. AuthnInstant records when the principal authenticated at the identity provider, and SessionNotOnOrAfter can describe the end of the IdP authentication session. That session value may be useful evidence, but it is not the same as the assertion replay window.

Rule Core

The checker turns parsed SAML timestamps into control rows. Each row has an Area, Status, Severity, Observed value, Evidence, and Recommended action so a reviewer can separate hard rejects from policy warnings.

Review Area Checked Signal Finding Pattern
Source parse XML, base64 XML, or SAMLResponse form/query payload. Invalid XML, compressed-looking payloads, encrypted-only responses, or missing assertions block timing review.
Conditions NotBefore, NotOnOrAfter, and interval order. Missing Conditions or missing upper bound fails. Missing NotBefore can warn when that policy is enabled.
Current-time validation Reference UTC time adjusted by clock skew. Too early or expired assertions fail when the reference time remains outside the Conditions interval after skew.
Assertion lifespan Conditions start to Conditions end, using IssueInstant as a fallback start when NotBefore is absent. Windows longer than the configured maximum assertion window warn because replay exposure is wider than policy.
SubjectConfirmationData Bearer confirmation NotOnOrAfter and optional lower bound. Missing bearer expiry fails. Expired, overlong, or assertion-outliving confirmation windows warn or fail.
AuthnStatement AuthnInstant, SessionNotOnOrAfter, and configured session duration. Future authentication times, missing required authentication times, expired sessions, and excessive IdP session duration are called out separately from assertion validity.

Reference-Time Logic

Clock skew is applied as leeway around the relying-party reference time. A future lower bound is still a failure when the reference time plus skew is before NotBefore. An expiry is still a failure when the reference time minus skew is at or after NotOnOrAfter.

valid = ( reference + skew ≥ NotBefore ) ∧ ( reference - skew < NotOnOrAfter )
Timestamp Scope How It Is Used
IssueInstant Assertion Records when the assertion was issued and supplies a fallback start for lifespan measurement when Conditions omit NotBefore.
NotBefore Conditions Sets the earliest valid instant. Future values beyond skew produce "Not yet valid" failures.
NotOnOrAfter Conditions or bearer confirmation Sets an exclusive upper bound. Reference time at or after this value, after skew, is treated as expired.
AuthnInstant AuthnStatement Records authentication time and should not be read as assertion expiry.
SessionNotOnOrAfter AuthnStatement Describes IdP session expiry when present and can warn separately from assertion and bearer confirmation timing.

Everyday Use & Decision Guide:

Start with a capture from the service provider side of the exchange. Paste the assertion XML, a base64 POST binding value, a hidden form input, or a form/query string containing SAMLResponse into SAML assertion or response. Use Partner label to name the IdP, SP, tenant, environment, or ticket so the summary and structured output remain traceable.

Leave Reference UTC time blank for a live check against the browser's current UTC clock. Enter an ISO timestamp such as 2026-05-06T10:15:00Z when you are replaying incident evidence and need repeatable output. Keep Clock skew allowance aligned with the relying-party policy, commonly 60 to 300 seconds for SAML integrations.

  • Use Maximum assertion window to flag Conditions intervals that are longer than the assertion replay policy.
  • Use Maximum bearer confirmation window to catch SubjectConfirmationData windows that last longer than the delivery proof should.
  • Open Advanced when you need to warn on missing NotBefore or require SessionNotOnOrAfter evidence for this integration.
  • Use Load valid sample and Load drift sample only to understand the output shape before testing a real capture.
  • Use Browse XML for a small local file under 1 MiB when copying from a support bundle is less reliable than loading the capture directly.

Read the summary before opening detailed tabs. Usable now means no Fail or Warn rows were produced by the selected timing policy. Review timing means at least one warning needs context. Reject now means a Fail row says the assertion should not be accepted under the current reference time and policy.

Do not treat a timing pass as SAML acceptance. Use Timing Control Matrix to fix timestamp issues, then verify XML signature, issuer key ownership, audience, destination, recipient, request binding, and replay handling in the relying-party verifier.

Step-by-Step Guide:

Review one SAML capture against one reference time so every table row and chart bar describe the same relying-party decision.

  1. Enter Partner label with a short traceable name such as acme-idp production or the incident ticket. The summary line should now name the integration being checked.
  2. Paste XML, a base64 SAMLResponse, or a form/query payload into SAML assertion or response. If the status says XML could not be found, paste decoded XML or a POST binding value instead of a compressed Redirect binding payload.
  3. Set Reference UTC time only when the review needs a fixed timestamp. If the field is blank, the summary uses the current browser UTC clock.
  4. Set Clock skew allowance, Maximum assertion window, and Maximum bearer confirmation window to match the verifier policy being audited.
  5. Open Advanced if local policy requires NotBefore or expects SessionNotOnOrAfter. Missing optional fields become Warn rows when those switches are enabled.
  6. Read the top summary. Check input means parsing failed, Reject now means at least one Fail row exists, and Review timing means warnings remain after parsing.
  7. Open Timing Control Matrix. Start with Fail rows, then Warn rows, using the Evidence and Recommended action columns to decide whether the IdP clock, lifetime policy, or verifier skew needs attention.
  8. Open Timestamp Ledger to confirm each parsed value, its UTC rendering, and its relative distance from the reference time.
  9. Open SAML Timing Window Chart when several windows exist. The vertical reference line helps show whether Conditions, bearer confirmation, and session windows align or drift apart.

Interpreting Results:

The strongest cue is the harshest Status in Timing Control Matrix. A single Fail should block acceptance even if other rows pass. Warn rows are policy or evidence concerns that may be acceptable after review, but they should not be hidden by a good-looking expiry time.

Output Cue Meaning Follow-Up
Source parse = Fail The input could not be turned into readable assertion timing evidence. Paste well-formed XML, a base64 POST binding value, or a decrypted assertion excerpt before judging the timestamps.
Current-time validation = Fail The reference time is outside the Conditions window after skew allowance. Reject the assertion at this reference time, then compare IdP and SP clocks and capture a fresh response if needed.
Assertion lifespan = Warn The Conditions interval is longer than the configured maximum assertion window. Shorten the IdP assertion lifetime or document why wider replay exposure is accepted.
SubjectConfirmationData = Fail or Warn The bearer confirmation expiry is missing, expired, too long, or extends beyond Conditions. Align bearer confirmation with the assertion validity window and verify recipient and request binding separately.
Session expiry = Warn The IdP session evidence is missing, expired, or longer than the configured session duration. Confirm whether the SP relies on IdP session lifetime. Do not confuse it with assertion expiry.

A clean timestamp ledger does not mean the assertion is safe to trust. Timestamps can be internally consistent while the signature is invalid, the audience is wrong, the recipient does not match the assertion consumer service, or the response belongs to another request. Use the result as timing evidence, not as the final SAML verdict.

Worked Examples:

Current POST response within a five-minute policy

A typical production capture has IssueInstant one minute before the reference time, Conditions NotBefore one minute before the reference time, Conditions NotOnOrAfter four minutes after it, and bearer confirmation expiring at the same four-minute mark. With Clock skew allowance at 300 seconds, Maximum assertion window at 5 minutes, and Maximum bearer confirmation window at 5 minutes, Timing Control Matrix can show Pass rows and the summary can show Usable now. The next review is signature, audience, recipient, and request binding in the service provider.

Identity provider clock ahead of the relying party

The drift sample places Conditions NotBefore eight minutes after the reference time and NotOnOrAfter more than two hours after the reference time. With 300 seconds of skew, reference time plus skew is still before NotBefore, so Current-time validation fails as Not yet valid. Assertion lifespan also warns because the Conditions window is much longer than the default five-minute policy. Treat this as a clock or token-lifetime problem before changing application code.

Bearer confirmation lasts beyond Conditions

An assertion can have a valid Conditions expiry at 10:05:00Z while its bearer confirmation NotOnOrAfter runs until 10:07:00Z. The checker reports the confirmation row as a warning because the delivery proof outlives the assertion's own validity window. The practical fix is to set bearer confirmation expiry at or before Conditions NotOnOrAfter, then rerun and confirm the Timestamp Ledger values agree.

Troubleshooting a compressed or encrypted capture

A Redirect binding value or encrypted-only response may not expose readable XML timestamps. The parser can report that the payload appears compressed or binary, or that only encrypted assertions are present. Decode or decrypt the assertion in an approved environment, paste the decrypted timing excerpt, and rerun before relying on any Check input result.

Responsible Use Note:

SAML timing evidence can affect release, incident, and access decisions, but it is not a complete SAML validation result. Use the output to isolate timestamp, skew, and lifetime issues, then let the service provider enforce signature, key, issuer, audience, recipient, destination, request, and replay checks.

Pasted assertions and selected files are parsed in the browser for this timing review. The checker does not submit the SAML source text to a server for analysis unless you separately share, copy, or upload the evidence somewhere else.

FAQ:

Does a timing pass mean the SAML response is valid?

No. A timing pass means the parsed timestamp evidence fits the selected reference time, skew, and lifetime policy. Signature, issuer key, audience, recipient, destination, request binding, and replay handling still have to pass in the relying-party verifier.

Which input formats can I paste?

Use readable XML, a base64 SAMLResponse from the POST binding, a hidden form input containing SAMLResponse, or a form/query string with that field. If the payload appears compressed or binary, decode it to XML before timing review.

Why does missing NotBefore show as a warning?

SAML Core allows an unspecified lower Conditions bound, but the Require NotBefore switch treats the missing value as local policy evidence. Turn it off only when the integration intentionally accepts assertions without that lower bound.

What should I do when the summary says Check input?

Fix the input before judging SAML timing. Common causes are malformed XML, a compressed Redirect binding payload, an encrypted-only response, or pasted text that does not contain an assertion or timing excerpt.

Does the checker upload the assertion?

No server submission is used for the timing analysis. The text area and file picker feed browser-side parsing, and exports are created from the data already shown in the result tabs.

Glossary:

Assertion
A SAML statement package issued by an identity provider for a relying service provider.
Conditions
The SAML element that can bound assertion validity with NotBefore and NotOnOrAfter.
NotBefore
The earliest instant when the assertion should be accepted under Conditions.
NotOnOrAfter
The exclusive upper instant at which a Conditions or bearer confirmation interval has ended.
SubjectConfirmationData
The SAML data that can constrain bearer delivery with recipient, request, address, and timing attributes.
AuthnStatement
The SAML statement that records authentication evidence such as AuthnInstant and optional session expiry.
Clock skew
Small allowed time leeway between identity provider and service provider clocks.

References: