SSOGEN / Learn / SAML Metadata Generator: Create SP or IdP Metadata XML

Free tool

SAML Metadata Generator: Create SP or IdP Metadata XML

A SAML metadata generator turns an entity ID, a few URLs and a public certificate into the XML file the other side imports. Fill in the form below and copy or download the result; nothing leaves your browser.

Plan a trial

Build the metadata

Choose service provider or identity provider and fill in the fields.
Select Build metadata.
Copy the result, or download it, with the Copy and Download metadata.xml buttons. A list of checks sits underneath.

To see a complete set of values first, select Fill in an Acme example.

Which side are you describing Service provider (the application) Identity provider (the sign-in system)

Entity ID required

A name for this party. It does not have to be reachable. The other side must enter it exactly.

Assertion consumer service URL (HTTP-POST) required

Where the identity provider sends the signed assertion. Add a second one below only if you need it.

Second assertion consumer service URL (optional)

Single logout URL (HTTP-Redirect, optional)

NameID format

Public certificate (PEM or plain base64) optional

The certificate that verifies signatures from this party. Public part only: a private key is refused.

More options

Require signed assertions (WantAssertionsSigned) This application signs its requests (AuthnRequestsSigned)

Valid for (days, optional)

Organization name

Organization URL

Technical contact email

Private by design. The XML is built in this page and nothing is uploaded. Metadata holds only public information. A certificate pasted here is read locally to show its dates and key size.

Everything runs in this page and nothing is uploaded. The certificate is read locally to show its subject, days left, RSA size, signature algorithm and SHA-256 fingerprint. If you paste a private key by mistake, the builder refuses it.

What SAML metadata is

SAML metadata is the XML file that describes one side of a single sign-on connection:

A service provider (SP) is the application users want to open. Its file lists where it receives assertions.
An identity provider (IdP) signs users in. Its file lists where it receives sign-in requests and which certificate it signs with.

This SAML metadata generator takes an entity ID, one or two URLs, a public certificate and a few options, and turns them into valid XML in your browser.

How to choose the entity ID and URLs

The other side compares these values character for character, so choose them once and keep them.

Entity ID. Choose a name that is stable and unique to this connection. A URL you control, such as https://erp.acme.example/saml/metadata, is the usual choice. It need not resolve, but it must never change after the other side has stored it. The specification caps it at 1,024 characters (SAML 2.0 metadata, section 2.2.1, read 2026-10-08). Avoid spaces and environment names that are likely to be renamed.
Use HTTPS everywhere. The assertion consumer service (ACS) URL carries a signed login to your application. An http:// address exposes it, and many identity providers will not register one. The builder warns on any http:// endpoint.
Exact match, including the path. To an identity provider that matches exactly, https://erp.acme.example/saml/acs and https://erp.acme.example/saml/acs/ are different addresses.
ACS for HTTP-POST. Browser sign-in uses the HTTP-POST binding, so the builder writes the ACS as HTTP-POST. The first ACS is the default; the optional second one gets index="1".
Identity provider URL. For an IdP, the single sign-on URL is offered for both HTTP-Redirect and HTTP-POST, plus an optional logout URL for HTTP-Redirect.

Which certificate to paste, and how to get the public part

Metadata carries only the public certificate, which lets the other side verify a signature. The matching private key stays on your server and never goes into a form, a ticket or a chat.

A PEM file can hold several blocks. Paste only the one between these lines:

-----BEGIN CERTIFICATE-----
(base64 text)
-----END CERTIFICATE-----

Private key. A block that begins BEGIN PRIVATE KEY or BEGIN RSA PRIVATE KEY is the private key; do not paste it.
BEGIN and END lines. The builder accepts the certificate with or without them.
Command line. To read a certificate’s subject and end date, run openssl x509 -in cert.pem -noout -subject -enddate.
Key size and algorithm. Use RSA 2,048 bits or more with a modern signature algorithm; the builder flags smaller keys and SHA-1.
Lifetime. Choose a lifetime you can manage, and plan the replacement before it expires.

The certificate rollover checklist on the checker page shows how to publish two certificates at once.

A commented example of what the builder produces

This is an Acme service provider file, shortened. The certificate value is a placeholder.

<?xml version="1.0" encoding="UTF-8"?>
<!-- entityID: the name the identity provider stores for this application -->
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    entityID="https://erp.acme.example/saml/metadata"
    validUntil="2027-01-06T00:00:00Z"> <!-- importers may refuse the file after this date -->
  <!-- WantAssertionsSigned: only accept signed assertions -->
  <SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true"
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <!-- the public certificate the IdP uses to verify our signatures -->
    <KeyDescriptor use="signing">
      <ds:KeyInfo><ds:X509Data>
        <ds:X509Certificate>BASE64-CERTIFICATE-PLACEHOLDER</ds:X509Certificate>
      </ds:X509Data></ds:KeyInfo>
    </KeyDescriptor>
    <!-- the identifier format we expect in the assertion -->
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <!-- where the assertion is delivered; index must be unique -->
    <AssertionConsumerService
        Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
        Location="https://erp.acme.example/saml/acs" index="0" isDefault="true"/>
  </SPSSODescriptor>
  <ContactPerson contactType="technical">
    <EmailAddress>saml-admin@acme.example</EmailAddress>
  </ContactPerson>
</EntityDescriptor>

Reading it from the top:

EntityDescriptor is the root. Its entityID identifies the whole file, and validUntil is the date after which the file is stale.
SPSSODescriptor says this entity acts as a service provider. WantAssertionsSigned tells the identity provider what to send. An IdP file uses IDPSSODescriptor and WantAuthnRequestsSigned instead.
KeyDescriptor use="signing" carries the certificate in base64, without line breaks.
NameIDFormat names the identifier the application uses to match users.
AssertionConsumerService is the delivery address, identified by its index. isDefault marks the one used when a request does not name one.
ContactPerson is optional and tells the other administrator whom to contact.

What happens next

Before you hand it over, paste the file into the SAML metadata checker for a second check.
Give it to whoever runs the identity provider, or upload it where the product asks for service provider metadata.

With SSOGEN as the identity provider:

Open Applications, then SAML, then Register SAML app.
On the Connection step, select Service provider metadata (optional) and choose your file.
Check the values SSOGEN fills in.

SSOGEN reads the entity ID, the HTTP-POST assertion consumer service URL and a signing certificate (not an encryption one). Check those values, because SSOGEN matches them exactly.

The wizard is described in register a SAML application. If SSOGEN is the service provider instead, see add a SAML identity provider. The overview is on the SAML integration page.

Messages SSOGEN shows for bad metadata

These messages are quoted from the wizard. The first four appear under the upload box; the rest appear beside the fields.

Message	What it means and the fix
That file is not valid XML. / That file could not be read as XML.	The file is damaged or is not XML, for example an HTML page saved by mistake. Download the file again, or use the builder’s Download metadata.xml.
That XML has no EntityDescriptor, so it is not SAML metadata.	Wrong file. The root element must be `EntityDescriptor`.
That metadata describes an identity provider, not a service provider. Upload the application’s own metadata.	You built or uploaded an IdP file. Switch the builder to service provider.
That metadata has no entity ID or no assertion consumer service URL.	The file is incomplete. Check `entityID` and the ACS `Location`, or enter the values by hand.
The service provider’s entity ID is required. It is in the application’s own SAML settings.	Fill in the entity ID.
The assertion consumer service URL must be https.	Change the ACS to an `https://` address.
The single logout URL must be https.	Same for the logout URL.
No service provider is registered here with that entity ID.	At sign-in, the application sent an entity ID SSOGEN does not know. Compare it with the one registered, character for character.

How do I create SAML metadata?

Enter the entity ID, ACS URL and public certificate in the builder above, select Build metadata, and download metadata.xml. Give that file to the identity provider.

What is the difference between SP and IdP metadata?

SP metadata lists where the application receives assertions. IdP metadata lists where the identity provider receives sign-in requests and which certificate it signs with.

Can I put the private key in the metadata?

No. Metadata holds only the public certificate. A private key pasted into any web form is exposed, and this builder does not accept one.

Does the generator upload my certificate?

No. It reads the certificate in your browser and makes no network request.

Where to go next

Check. Check an existing file with the SAML metadata checker.
Test. Start a test sign-in with the SAML request builder.
Trace. Follow a failing sign-in with the SAML tracer.
Certificate. For a signing certificate, generate a self-signed certificate.

Sources, all read 2026-10-08: SAML 2.0 metadata specification.