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

SAML metadata is the contract document that tells a service provider and an identity provider how to find each other. It names the entity, declares roles, lists endpoints, advertises bindings, and carries signing or encryption key material. When metadata is wrong, single sign-on failures often appear later as vague login loops, audience mismatches, missing assertion consumers, or certificate trust errors.

The central identifier is the entityID. Partners configure that exact value as issuer, audience, or relying-party identity depending on their role. Whitespace, duplicate values, stale tenant URLs, and copied sample identifiers can break an integration even when the XML is well formed.

Role descriptors decide which endpoint rules matter. Service provider metadata needs Assertion Consumer Service endpoints so an identity provider knows where to send assertions. Identity provider metadata needs Single Sign-On Service endpoints and signing-key evidence so a service provider can send users to the right login service and validate issued assertions.

Endpoint bindings matter because SAML supports several transport profiles. Browser SSO commonly uses HTTP-Redirect, HTTP-POST, or HTTP-Artifact. SOAP, PAOS, and URI bindings may be valid in other contexts, but they often need review when they appear in ordinary browser SSO metadata.

Certificates and metadata freshness are operational risks. A valid-looking XML file can still contain expired keys, no rollover room, missing signatures, localhost endpoints, or a validity window so long that stale trust is hard to retire. Metadata validation should catch those issues before an import or partner exchange.

How to Use This Tool:

Start by choosing the kind of metadata you expect, then paste or import the XML. The validator runs in the browser and reports structural readiness; it does not perform cryptographic XML signature verification.

Enter an Integration label so copied evidence stays tied to a partner, tenant, ticket, or environment.
Choose a Review profile: service provider metadata, identity provider metadata, federation aggregate, or auto-detect inventory. The profile changes expected roles, signature policy, endpoint severity, and entity-count limits.
Set the Endpoint policy. Production HTTPS treats HTTP and localhost as warnings, strict signed exchange treats them as failures, and lab mode keeps local endpoints informational.
Paste metadata XML or browse/drop one XML or text file. The sample buttons load synthetic SP and IdP rollover examples.
Adjust the certificate warning horizon and maximum metadata validity window to match local import policy.
Open Advanced for signed metadata, default ACS, localhost HTTP, and maximum entity-count expectations.
Read Metadata Control Matrix first, then inspect role, endpoint, certificate, readiness gauge, and JSON evidence.

Interpreting Results:

The headline score is an import-readiness estimate from the control matrix. Fail checks can block import or break SSO. Warn checks need policy review. Info rows are evidence or context rather than blockers.

Entity Role Inventory shows each entity, role descriptor, protocol support, endpoint count, key descriptors, NameID formats, signing flags, refresh window, and contact evidence. Entity Endpoint Ledger lists each service, binding, location, index or default marker, and status. Certificate Ledger shows X.509 subject, expiry, days left, fingerprint, and status.

SAML metadata result interpretation cues
Finding	Likely meaning	What to verify
`Missing ACS`	SP metadata does not advertise where assertions should be posted.	Add at least one AssertionConsumerService with binding, location, and index.
`No SSO endpoint`	IdP metadata lacks a login service endpoint.	Export complete IdP metadata or switch to the correct review profile.
`Certificate warning`	A certificate expires inside the selected warning horizon.	Plan rollover with both partners before the key expires.
`Signature absent`	No signature element was detected.	Require signed metadata for federation or untrusted transport, then verify it outside the page.

A high score does not prove trust. The validator reports signature presence only, parses certificate dates locally, and checks endpoint policy. Final acceptance still needs the SAML product's importer, XML signature verification when required, partner confirmation, and a real SSO test.

Technical Details:

SAML metadata is usually rooted at EntityDescriptor for one entity or EntitiesDescriptor for an aggregate. Entity descriptors contain role descriptors such as SPSSODescriptor and IDPSSODescriptor. The selected profile tells the validator whether a specific role is required or whether any recognized role can be inventoried.

Endpoint status combines binding checks and URL checks. Missing bindings and missing locations fail. Unknown binding URIs warn. Non-browser bindings are informational, warning, or failure depending on the endpoint policy and service type. HTTP and localhost severity also depend on the endpoint policy and the local-HTTP switch.

Formula Core:

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

Critical failures carry the largest score reduction, followed by high, medium, and low severity checks. Warnings use smaller penalties than failures. The score is helpful for triage, but the control matrix remains authoritative because one critical failure can matter more than the final percentage.

Rule Core:

SAML metadata validation rule core
Area	Rule	Reason
Root element	Must be `EntityDescriptor` or `EntitiesDescriptor`.	SAML responses, assertions, and config excerpts are not metadata documents.
SP profile	Requires `SPSSODescriptor` and at least one `AssertionConsumerService`.	The IdP needs an ACS location for assertions.
IdP profile	Requires `IDPSSODescriptor`, SSO endpoint evidence, and signing-key material.	The SP needs login service and token-signing trust evidence.
Validity window	Missing `validUntil` warns; expired or unparseable values fail; values beyond the selected horizon warn.	Metadata should be refreshable and retire stale endpoints or keys.
Certificates	Expired, unreadable, or not-yet-valid certificates fail; certificates inside the warning horizon warn.	Signing-key rollover needs time before an outage.
Signature presence	If signed metadata is required and no signature element exists, the check fails.	Presence is only a signal; cryptographic verification must happen in a trusted SAML stack.

Certificate parsing reads DER fields enough to report subject, issuer, serial, validity dates, and a local fingerprint when browser cryptography is available. It does not build a certificate path, check revocation, or prove that the metadata signature is valid.

Limitations:

The validator is a metadata readiness checker, not a complete SAML trust engine. It does not verify XML signatures cryptographically, validate certificate chains, check revocation, perform live endpoint probes, or import the metadata into a specific identity product.

Metadata XML is analyzed in the browser. Avoid pasting partner material you are not allowed to inspect on this machine, and remove private notes from the integration label before sharing exports.

Worked Examples:

SP metadata with two ACS endpoints. If both endpoints have indexes but none is marked default, the result may warn when default ACS is required. Mark the intended default or confirm that the IdP imports the correct index.

IdP rollover metadata. Metadata with two signing certificates can be healthy when both are current and the SP trusts both during rollover. If one expires inside the warning horizon, plan partner update timing before removing the old key.

Troubleshooting a parse error. If the source says XML parser error, normalize line endings and confirm the pasted text contains complete metadata XML, not a SAML response, copied HTML page, or escaped XML string.

Lab endpoint in production policy. http://localhost may be acceptable in lab mode but warn or fail under production and strict policies. Switch policy only when the metadata is truly local test material.

FAQ:

Does a 100% score mean the metadata is trusted?

No. It means the visible readiness checks passed. Trust still depends on signature verification, certificate trust, partner configuration, and an end-to-end SSO test.

Why is a signature element not enough?

The validator detects signature presence but does not validate the XML signature against a trusted key. Use your SAML stack or a dedicated XML signature verifier for that step.

Why does missing validUntil matter?

Without a bounded validity window, consumers have less evidence for when stale endpoints or signing keys should be retired.

Why are localhost URLs flagged?

Localhost endpoints are usually test artifacts. Production and strict policies mark them for review or failure so they are not exchanged accidentally.

What should I do with an expired certificate row?

Replace the certificate in metadata, coordinate rollover with the partner, and retest the import. Do not rely on an expired signing key for production SSO.

Glossary:

EntityDescriptor: A SAML metadata element that describes one entity and its roles.
EntitiesDescriptor: A metadata aggregate containing multiple entity descriptors.
entityID: The stable identifier partners configure for the SAML entity.
ACS: Assertion Consumer Service, the SP endpoint that receives SAML assertions.
SSO endpoint: The IdP endpoint used to start or receive browser SSO requests.
KeyDescriptor: Metadata key material for signing, encryption, or unspecified use.
validUntil: The metadata timestamp that tells consumers when the document should no longer be accepted.