SAML Metadata Validator

Integration label:

Name the metadata exchange or SSO integration under review.

Review profile:

Choose the metadata shape you expect before interpreting missing ACS, SSO, SLO, or certificate evidence.

Endpoint policy:

Use strict HTTPS for production exchange; lab mode keeps localhost and HTTP findings as review notes.

SAML metadata XML:

Paste metadata XML, or browse/drop one .xml or .txt file. The default sample is synthetic and safe.

Metadata parse notes

{{ warning }}

Certificate warning horizon: {{ certificateWarningLabel }}

Use 30 to 90 days for normal signing-key rollover planning.

days

Maximum metadata validity: {{ metadataValidityLabel }}

Long validity windows make stale endpoints and signing keys harder to retire.

days

Require signed metadata:

{{ requireSignedMetadataBool ? 'Signature presence required' : 'Signature presence observed only' }}

Turn on for federation imports where signed metadata is part of the trust contract.

Require default ACS:

{{ requireDefaultAcsBool ? 'Default ACS expected' : 'ACS index review only' }}

Keep on for production SP metadata exchanged with IdPs that import a single default ACS.

Allow HTTP localhost endpoints:

{{ allowHttpLocalBool ? 'Local HTTP tolerated' : 'All HTTP endpoints reviewed' }}

Use only for local development metadata that will not be exchanged for production SSO.

Maximum entity count:

Use lower values for single-partner exchange and higher values for federation aggregates.

{{ header }}	Copy
{{ cell.text }} {{ cell.text }}
No rows available {{ emptyTableMessage(tab.key) }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Single sign-on depends on two systems agreeing about identity, message destinations, and signing keys before a user ever reaches the login button. Security Assertion Markup Language (SAML) metadata is the XML trust map for that agreement. It names the entity, declares service provider or identity provider roles, lists browser endpoints, records supported bindings, and publishes public key material for signatures, encryption, or related checks.

The XML can look routine, but small metadata mistakes create confusing outages. A staging entityID copied into production can make an assertion look like it was issued for the wrong audience. A missing Assertion Consumer Service (ACS) endpoint leaves an identity provider with nowhere to post the response. An expired signing certificate can break trust even when every endpoint URL is correct. A long or missing validity window can keep stale partner data alive after a key rollover or migration.

Service provider: The application or relying party that receives the SAML assertion and usually publishes ACS endpoints.
Identity provider: The login authority that authenticates users and usually publishes SSO endpoints and signing keys.
Entity ID: The stable identifier partners configure as issuer, audience, or relying-party identity.
Binding: The SAML transport method, such as HTTP-POST, HTTP-Redirect, HTTP-Artifact, SOAP, PAOS, or URI.

Metadata review is common during SaaS onboarding, identity provider migration, certificate rollover, federation aggregate updates, and incident response after SSO starts looping or rejecting assertions. A parser can confirm that angle brackets are balanced, but import readiness depends on role evidence, endpoint policy, key dates, signature expectations, and freshness windows.

Bindings and endpoints also need context. HTTP-POST and HTTP-Redirect are common for browser SSO, while HTTP-Artifact adds back-channel resolution. SOAP, PAOS, and URI bindings can be valid in specialized flows, but they deserve extra review in ordinary browser SSO metadata. Plain HTTP and localhost URLs are useful in labs and dangerous in production exchange.

A metadata file cannot prove live trust by itself. It can show that the declared roles, endpoints, keys, and dates are coherent enough to continue. Final acceptance still depends on the importing product, partner policy, XML signature verification when required, and an end-to-end SSO test with the real tenant configuration.

How to Use This Tool:

Choose the review shape first, then inspect the control matrix before drilling into role, endpoint, certificate, and JSON evidence. The XML is analyzed in the browser, and the result is a readiness review rather than a cryptographic trust decision.

Enter an Integration label for the partner, tenant, ticket, or environment so copied rows and exported evidence remain traceable.
Select a Review profile. Use Service provider metadata when the file should contain SPSSODescriptor and ACS endpoints. Use Identity provider metadata when it should contain IDPSSODescriptor, SSO endpoints, and signing-key evidence. Use Federation aggregate for multi-entity signed exchanges, or Auto-detect inventory when you only need an inventory pass.
Federation aggregate turns on signed-metadata expectations by default and raises the entity cap. Auto-detect inventory keeps lab-style endpoint findings as review notes.
Set the Endpoint policy. Production HTTPS treats HTTP and localhost as warnings, strict signed exchange treats them as failures, and lab mode keeps local endpoint findings informational.
Paste the SAML metadata XML, browse for an XML or text file, or drop a file on the text area. If the parser complains, use Normalize LF and confirm the pasted content starts with EntityDescriptor or EntitiesDescriptor, not a SAML response or copied HTML page.
Fix an XML parse failure before reviewing role, endpoint, certificate, or readiness rows. The downstream tables need a parseable metadata document.
Set Certificate warning horizon and Maximum metadata validity to match the review window used by your team or federation. Typical rollover reviews use 30 to 90 days for certificate warning time.
Open Advanced when signed metadata, a default ACS, localhost HTTP, or a maximum entity count should be enforced for this exchange.
Read Metadata Control Matrix first. Then use Entity Role Inventory, Entity Endpoint Ledger, Certificate Ledger, SAML Metadata Readiness Gauge, and JSON to collect the evidence needed for partner review.

Interpreting Results:

The summary reports Import blockers, Review needed, or Import-ready snapshot based on the control matrix. The percentage is useful for triage, but the row-level findings matter more than the number. One critical failure can make otherwise healthy metadata unusable.

Pass means the visible evidence satisfied the selected profile. Warn means the metadata may be acceptable only with a policy decision or partner confirmation. Fail means the row should be fixed before import. Info gives context that does not reduce readiness by itself.

SAML metadata result interpretation guide
Result cue	What it means	Where to verify next
`Missing ACS` or `AssertionConsumerService` failure	SP metadata does not give the identity provider a usable assertion destination.	Check `Entity Endpoint Ledger` for binding, location, index, and default marker.
`SingleSignOnService` failure	IdP metadata lacks a login endpoint for the selected review profile.	Confirm the file is IdP metadata or switch the `Review profile`.
`X.509 certificates` warning or failure	A certificate is expired, unreadable, not yet valid, or inside the warning horizon.	Use `Certificate Ledger` for subject, validity date, days left, fingerprint, and status.
`Metadata signature` absent	No signature element was detected, or signed metadata was required and missing.	Verify signed metadata with the SAML product or a dedicated XML signature validator.
HTTP, localhost, or uncommon binding warning	The endpoint may be valid for a lab or non-browser flow, but risky for production browser SSO.	Compare `Endpoint policy` with the endpoint rows before accepting the metadata.

Do not treat a high readiness score as proof that the partner is trusted. The checker reports structure, dates, endpoint policy, key material, and signature presence. It does not import the file into your SAML product, build a certificate trust path, check revocation, probe live URLs, or verify XML signatures cryptographically.

Technical Details:

SAML metadata is normally rooted at one EntityDescriptor or at an EntitiesDescriptor aggregate. Each entity can contain role descriptors, including SPSSODescriptor and IDPSSODescriptor. The role descriptor carries protocol support, endpoints, key descriptors, NameID formats, and signing flags. The same entity can technically advertise more than one role, but bilateral SSO exchanges usually expect a clear SP or IdP shape.

The validator reads direct entity descriptors from an aggregate and also warns if entity descriptors are found nested deeper than expected. It checks for the SAML metadata namespace, duplicate or missing entityID values, whitespace in identifiers, role/profile mismatch, SAML 2.0 protocol support, endpoint URL shape, certificate dates, signature presence, and metadata validity. cacheDuration is shown as refresh evidence, while the readiness check focuses on a parseable validUntil value and the selected maximum validity horizon.

Rule Core:

SAML metadata validation rule core
Area	Rule applied	Why it matters
Root element	Accepts `EntityDescriptor` or `EntitiesDescriptor`; other roots fail.	SAML responses, assertions, and configuration fragments are not metadata documents.
Entity ID	Every entity needs a non-blank, unique `entityID` without whitespace.	Partners use the value as a stable issuer, audience, or relying-party identifier.
SP profile	Requires `SPSSODescriptor` and at least one `AssertionConsumerService`.	An identity provider needs an ACS endpoint before it can deliver assertions.
IdP profile	Requires `IDPSSODescriptor`, SSO endpoint evidence, and a signing or unspecified X.509 certificate.	A service provider needs a login endpoint and token-signing trust evidence.
Validity	Missing `validUntil` warns; expired or unparseable values fail; dates beyond the selected horizon warn.	Consumers need a bounded refresh window so stale endpoints and keys can be retired.
Signature presence	If signed metadata is required and no `ds:Signature` element is present, the row fails.	Presence is only a signal; the actual XML signature still needs trusted verification.

Endpoint review combines SAML binding recognition with URL policy. Missing bindings and missing locations fail. Unknown binding URIs warn. HTTP and localhost are judged by the selected endpoint policy, with the localhost switch allowing local HTTP endpoints to remain informational for lab material.

Endpoint policy severity table
Endpoint policy	HTTP endpoint	Localhost endpoint	Non-browser binding
`Production HTTPS review`	Warn	Warn	Info
`Strict signed exchange`	Fail	Fail	Warn
`Lab or local metadata`	Info	Info	Info

Formula Core:

The readiness score starts at 100 and subtracts penalties from failed and warning controls. The exact score is bounded from 0 to 100 and rounded to the nearest whole percent.

\begin{array}{rcl} penalty & = & \sum penalty for every failed or warning control \\ readiness score & = & round (clamp (100 - penalty, 0, 100)) \end{array}

Readiness scoring penalties by severity
Severity	Fail penalty	Warn penalty
Critical	38	22
High	26	14
Medium	17	9
Low	9	5
Info	0	0

A practical example shows why row detail matters. One critical failure and one high warning subtract 38 + 14, producing a readiness score of 48%. That same score could also come from several medium warnings, but the remediation priority is different. Always use the control matrix to see which checks produced the score.

Certificate parsing reads base64 X.509 material enough to report subject, issuer, serial, not-before and not-after dates, days left, and a SHA-256 fingerprint when browser cryptography is available. It does not validate the certificate chain, check revocation, enforce certificate usage extensions, or prove that a metadata signature is valid. That distinction matches SAML metadata practice: the embedded certificate is primarily a public key container, while metadata acceptance and signature verification establish the trust decision.

The main review bounds are user adjustable. Certificate warning horizon accepts 1 to 730 days, maximum metadata validity accepts 1 to 1095 days, and maximum entity count accepts 1 to 5000 entities. Those bounds let a single partner exchange and a federation aggregate use different tolerance levels without changing the underlying SAML rules.

Limitations and Privacy Notes:

The checker is a metadata readiness review, not a complete SAML trust engine. Use it before import, partner handoff, or troubleshooting, then confirm the result in the product that will actually consume the metadata.

XML signature presence is detected, but cryptographic XML signature verification is not performed.
X.509 dates and fingerprints are reviewed locally, but certificate path validation and revocation checks are not performed.
Endpoint URLs are parsed and classified, not contacted.
The pasted XML is analyzed in the browser. Avoid pasting partner metadata you are not allowed to inspect on this machine, and remove sensitive ticket notes from Integration label before sharing exports.

Advanced Tips:

Use Strict signed exchange with Require signed metadata for federation aggregates or partner exchanges where the metadata file itself must be signed before import.
Keep Require default ACS enabled for production SP metadata with multiple ACS endpoints unless the importing identity provider is known to select the intended index reliably.
Lower Maximum entity count for single-partner exchanges so an accidentally pasted aggregate is flagged before endpoint and certificate rows become noisy.
Set Certificate warning horizon to the team's real rollover lead time. A 90-day horizon is useful only when owners can rotate keys and update partners inside that window.
Use Allow HTTP localhost endpoints only for lab metadata. It changes localhost HTTP findings to informational, but ordinary HTTP endpoints still follow the selected endpoint policy.
Export the Metadata Control Matrix and Certificate Ledger together when opening a partner ticket, because readiness score alone does not show which row needs remediation.

Worked Examples:

Production SP metadata with one default ACS. A service provider file with the entity ID urn:example:sp:app has one SPSSODescriptor, an HTTP-POST ACS endpoint labeled /saml/acs, one signing certificate valid for 120 days, and validUntil 120 days ahead. With Service provider metadata, Production HTTPS review, a 90-day certificate warning horizon, and 180-day maximum validity, the Metadata Control Matrix should be mostly Pass rows and the summary should read as an Import-ready snapshot.

IdP rollover inside the warning horizon. An identity provider publishes two signing certificates during rollover, one expiring in 35 days and one valid for the next year. With Identity provider metadata and a 90-day warning horizon, Certificate Ledger should show the older certificate with about 35 days left and a warning status. The result can still be acceptable when both partners have a planned rollover date, but X.509 certificates should remain a documented Warn row until the old key is removed.

Strict exchange with lab endpoints. SP metadata that lists a plain-HTTP localhost ACS may be useful for a developer test, but under Strict signed exchange it should produce Endpoint URLs failure evidence. If Require signed metadata is also enabled and no ds:Signature exists, the summary should move to Import blockers. Switch to lab mode only when the file is not intended for production partner exchange.

Parser error from copied content. A paste that begins with an HTML error page, a SAML response, or an escaped XML string can trigger an XML parser error before metadata rules run. Normalize line endings, paste the raw metadata document, and confirm the root is EntityDescriptor or EntitiesDescriptor. Once parsing succeeds, Metadata Control Matrix will show role and endpoint findings instead of only the XML parse failure.

FAQ:

Does a 100% readiness score mean the metadata is trusted?

No. It means the visible readiness checks passed for the selected profile and policy. Trust still depends on XML signature verification when required, accepted keys, partner configuration, and a real SSO test.

Why does the validator care about validUntil?

validUntil gives consumers a clear retirement point for metadata. Missing, expired, unparseable, or unusually long validity windows can leave stale endpoints and keys in use longer than intended.

Can an expired certificate still appear in SAML metadata?

It can appear, but the certificate ledger marks expired and unreadable certificates as failures. For production exchange, replace expired signing material and coordinate rollover before relying on the metadata.

Why are HTTP or localhost URLs flagged?

They are often lab leftovers. Production and strict endpoint policies warn or fail them so a test ACS, SSO, or logout endpoint is not exchanged with a partner by accident.

What should I do when no table rows appear?

Fix the parse error first. The result tables stay empty or limited when the XML cannot be parsed or when no role, endpoint, or certificate elements exist for that tab.

Does signature presence mean the signature is valid?

No. The checker can detect a ds:Signature element, but a trusted SAML stack or XML signature verifier must validate the signature against accepted key material.

Glossary:

EntityDescriptor: A SAML metadata element that describes one entity and the roles it supports.
EntitiesDescriptor: A metadata aggregate that contains one or more entity descriptors.
entityID: The stable identifier partners configure as issuer, audience, or relying-party identity.
ACS: Assertion Consumer Service, the service provider endpoint that receives SAML assertions.
SSO endpoint: The identity provider endpoint used for browser single sign-on requests.
KeyDescriptor: Metadata key material for signing, encryption, or unspecified SAML use.
validUntil: The timestamp that tells consumers when metadata should no longer be accepted.
Binding: The transport method used for a SAML service endpoint.

References:

Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS, 15 March 2005.
SAML V2.0 Metadata Interoperability Profile Version 1.0, OASIS, 4 August 2009.
Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS, 15 March 2005.