Testing SAML SSO: the checklist that catches real failures

A SAML integration that works in the demo is not tested. The failures that reach production are the ones nobody tried: the expired certificate, the IdP-initiated login, the attribute that changed, the user who was deactivated.

This is the test plan that catches them.

Before you test: capture the messages

You cannot debug SAML without seeing the XML. Two ways:

• Browser developer tools: the SAML response is a form POST to the ACS URL; the request body is the base64-encoded response.
• A SAML tracer extension: browser extensions that decode SAML requests and responses as they pass.

Decode the base64 and read the XML. Every failure below is visible there.

Test 1: metadata exchange

• The SP's entity ID matches the IdP's configured audience exactly (trailing slashes count).
• The ACS URL in the IdP configuration matches the SP's endpoint.
• The signing certificate on the SP is the one the IdP currently uses.
• The binding (HTTP-POST vs HTTP-Redirect) matches what the SP expects.

A mismatch here shows up as a signature or audience error, not as a metadata error.

Test 2: SP-initiated login, happy path

1. Start at the application, not at the IdP.
2. Sign in with a real user.
3. Confirm the assertion contains the expected NameID and attributes.
4. Confirm the application created the session and the user lands where intended.

Check the response's InResponseTo matches the request ID — some SPs do not send it, and some IdPs require it.

Test 3: negative cases

These are the tests that matter:

If tampering is accepted, stop and fix signature validation before anything else.

Test 4: IdP-initiated login

If you plan to support portal tiles:

1. Start at the IdP's app portal.
2. Click the application tile.
3. Confirm the SP accepts the unsolicited response and that RelayState lands the user on the right page.

Many SPs reject unsolicited responses. If yours does, decide whether to support IdP-initiated at all. See SP-initiated vs IdP-initiated SSO.

Test 5: attributes and mapping

• Every attribute the application needs is present and correctly named.
• Group or role attributes map to the expected permissions.
• A user with no optional attribute still logs in (unless the app requires it).
• Names with non-ASCII characters survive the encoding.

Attribute problems often appear as "user logs in but sees an empty account".

Test 6: logout

• SP-initiated logout ends the SP session and, if configured, the IdP session.
• IdP-initiated logout ends the SP session.
• An application that does not support SLO is documented as such.

Remember that front-channel logout depends on browser behavior and can fail silently. See SAML single logout.

Test 7: certificate rotation

Do this on purpose, before production forces it:

1. Rotate the IdP signing certificate.
2. Update the SP's metadata.
3. Confirm login still works.
4. Remove the old certificate and confirm login still works.

If the SP does not support overlapping certificates, you need a maintenance window — better to know that in advance.

Test 8: the real identity providers

Test against the IdPs your customers actually use:

• Okta — the most common enterprise IdP.
• Microsoft Entra ID — the second most common.
• Google Workspace — common in mid-market.
• One local IdP you control (Casdoor or Keycloak) for repeatable tests.

Each behaves slightly differently in attribute names, binding support and IdP-initiated behavior.

A test matrix to keep

Run it before every upgrade of the identity provider or the application's SAML library. Most regressions are library upgrades that changed a default.

Related reading: set up Casdoor as a SAML IdP, SAML assertions and SAML metadata.