What this tool checks
SAML metadata checks that matter during SSO configuration and troubleshooting
SAML metadata is the configuration contract between an identity provider (IdP) and a service provider (SP). A single incorrect entity ID, endpoint or signing certificate can prevent federation from working even when the rest of the configuration looks correct. This validator surfaces the fields engineers most often compare during a new integration, certificate rollover, migration or production incident.
Entity & role
Detects EntityDescriptor, entity ID, IdP/SP roles and metadata validity.
SSO endpoints
Extracts SSO, SLO, ACS and artifact resolution endpoints and their SAML bindings.
Signing behavior
Shows AuthnRequestsSigned, WantAssertionsSigned and related signing expectations.
X.509 certificates
Parses embedded certificates, expiry dates, issuer/subject, serial number and SHA-256 fingerprint.
NameID formats
Lists NameID formats published by the IdP or SP so they can be compared with application requirements.
Configuration warnings
Flags missing core fields, non-HTTPS endpoints, expiring metadata/certificates and selected SHA-1 references.
How to use it
Validate SAML metadata in three steps
- Paste or upload the XML. Use the metadata downloaded from your IdP, SP or SaaS vendor.
- Run Validate metadata. The parser analyzes the XML locally in your browser.
- Compare the findings with the live SSO configuration. Pay particular attention to entity IDs, endpoints and certificates.
Privacy note: SAML metadata is normally less sensitive than a live SAML assertion, but it can still expose internal hostnames or configuration details. This page performs its analysis client-side and does not submit the pasted metadata to InfraSec Tools.
Troubleshooting targets
Common SAML metadata problems this validator can help identify
1. Entity ID mismatch
The IdP and SP must agree on the identifiers used for federation. If the SP entity ID configured in the IdP differs from the identifier the application expects, authentication can fail with audience, issuer or trust-related errors.
Check next: compare the metadata entityID with the application configuration and, for a runtime failure, the assertion AudienceRestriction.
2. Incorrect ACS or SSO endpoint
An outdated Assertion Consumer Service (ACS) URL or IdP Single Sign-On URL is common after hostname changes, environment migrations, vanity URL changes, reverse-proxy updates or vendor upgrades.
Check next: compare the metadata endpoint with the URL actually used in the SAML request/response flow.
3. Expired or unexpected signing certificate
The certificate published in metadata must align with the key used for SAML signing when the relying party validates signatures. Certificate rollovers can fail when one side still trusts only the previous certificate.
Check next: compare the SHA-256 fingerprint shown here with the certificate configured on the other side of the trust.
4. Multiple ACS endpoints
SP metadata can publish several ACS endpoints. This is valid, but it becomes a troubleshooting target when the IdP sends a response to an endpoint the application does not expect.
Check next: review the ACS index, isDefault value and the destination/recipient values in the actual SAML response.
5. Signing expectation mismatch
AuthnRequestsSigned and WantAssertionsSigned communicate expectations, but they do not prove that a runtime message was actually signed or successfully verified.
Check next: inspect the live AuthnRequest or SAML Response when the metadata settings appear correct.
6. Metadata or endpoints using unexpected HTTP URLs
The validator highlights non-HTTPS endpoints for review. Development environments may intentionally use HTTP, but production SSO endpoints normally warrant HTTPS.
Engineer notes
Practical SAML troubleshooting notes
Metadata can be correct while runtime SSO still fails
Metadata tells you what each party publishes. It does not show the actual issuer, audience, destination, timestamps, attributes or signature used in a failing transaction. When metadata checks out, inspect the real SAML request and response next.
Certificate validity is not the same as trust
A certificate can be unexpired but still be the wrong certificate for the trust. Compare fingerprints and confirm which certificate the IdP or SP is actively using after a rollover.
Entity ID is an identifier, not necessarily a reachable URL
Many entity IDs look like URLs, but they do not have to resolve in a browser. Treat the value as an exact identifier and compare it literally unless the product documentation says otherwise.
Reverse proxies can create endpoint confusion
Applications behind load balancers or proxies can publish internal or outdated URLs if forwarded-host/scheme handling is wrong. Compare externally reachable URLs with the metadata and runtime messages.
FAQ
SAML metadata validator questions
What is SAML metadata?
SAML metadata is XML that describes a SAML entity and its supported roles, identifiers, endpoints, bindings and cryptographic key material. It is commonly exchanged between an IdP and SP during federation setup.
Can I validate both IdP and SP metadata?
Yes. This tool detects IDPSSODescriptor and SPSSODescriptor content and applies role-specific endpoint and configuration checks.
Does the validator upload my SAML metadata?
No. The metadata parser and certificate inspection run in your browser.
Does it validate the XML signature on signed metadata?
Not yet. The current version detects metadata structure, configuration values and embedded certificates, but it does not cryptographically verify a metadata XML signature.
Does it perform full OASIS XML Schema validation?
No. V2 performs XML parsing plus targeted SAML metadata structural and semantic checks. Full XSD validation is a separate capability we may add later.
Why does my SP metadata show no certificate?
A certificate is displayed only when the metadata contains an embedded X.509 certificate inside a KeyDescriptor. Some SP metadata does not publish key material, depending on how the integration is configured.
Validation scope and limitations
This version performs XML parsing, targeted SAML 2.0 metadata structural/semantic checks and embedded X.509 certificate inspection. It does not perform full OASIS XSD validation, metadata XML-signature verification, certificate-chain trust validation, OCSP/CRL checks or live endpoint testing.
Technical review
Built for real SSO troubleshooting
This tool is built and technically reviewed by Mahesh Paul, an Identity and Access Management / Single Sign-On engineer with 25+ years of experience across enterprise authentication, federation, MFA and user lifecycle management.
Last technical review: August 12, 2026
About the engineer →