SAML Bindings and NameID Formats

ShibbDebugger includes diagnostic commands for reviewing SAML binding declarations and NameID formats advertised in XML metadata. These checks help identify configuration differences that may affect federation interoperability.

What Is a SAML Binding?

A SAML binding defines how a SAML protocol message is transported.

For example, a binding may specify whether a message is transmitted through an HTTP redirect, HTTP POST, or SOAP.

Federation participants must support compatible bindings for the operations they perform.

Check SAML Bindings

How to Use

  1. Select Check SAML Bindings.
  2. Upload a SAML metadata XML file.
  3. Click Execute Command.
  4. Review the binding coverage report.

Binding Types Checked

ShibbDebugger checks for five predefined bindings.

BindingPurpose Described by the Tool
HTTP-RedirectLogin and logout requests
HTTP-POSTSSO message transport
HTTP-POST-SimpleSignAlternative signed POST transport
SOAPAttribute or artifact resolution
SAML 1.0 SOAPLegacy SAML 1.x interoperability

Exact Binding Identifiers

HTTP-Redirect

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

HTTP-POST

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

HTTP-POST-SimpleSign

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign

SOAP

urn:oasis:names:tc:SAML:2.0:bindings:SOAP

SAML 1.x SOAP

urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding

Services Examined

The checker searches for binding declarations within:

  • SingleSignOnService
  • SingleLogoutService
  • ArtifactResolutionService
  • AttributeService

It collects distinct binding identifiers found in those service elements.

Understanding the Report

A present binding is marked:

✓

A missing binding is marked:

✗

Example:

✓ urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect

✗ urn:oasis:names:tc:SAML:2.0:bindings:SOAP

Important Interpretation

The command describes its predefined binding list as expected or required.

However, not all five bindings are universally required for every SAML deployment.

For example, a deployment that does not use artifact resolution may have no reason to publish an ArtifactResolutionService endpoint.

Likewise, legacy SAML 1.x bindings may be unnecessary.

A missing binding should therefore be treated as a compatibility observation, not automatically as a configuration defect.


What Is a NameID?

A SAML NameID identifies a subject within an authentication or federation exchange.

The identifier's format determines how that value is represented or interpreted.

Examples include transient and persistent identifiers.

Check NameID Formats

How to Use

  1. Select Check NameID Formats.
  2. Upload a SAML metadata XML file.
  3. Click Execute Command.
  4. Review the detected NameID formats.

Formats Checked

ShibbDebugger checks the presence of three predefined identifiers.

FormatMeaning
TransientShort-lived subject identifier
PersistentStable subject identifier scoped to federation relationships
Shibboleth 1.x NameIdentifierLegacy identifier format

Transient

urn:oasis:names:tc:SAML:2.0:nameid-format:transient

Transient identifiers are designed for temporary identification and generally should not be used as durable account identifiers.

Persistent

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

Persistent identifiers support stable subject recognition across multiple sessions under the relevant federation model.

Legacy Shibboleth Identifier

urn:mace:shibboleth:1.0:nameIdentifier

This identifier is associated with older Shibboleth conventions.

It may be relevant for legacy interoperability.

Additional Formats

The command also reports NameID formats that fall outside its predefined list.

These are described as unexpected in the generated report.

Such formats are not necessarily invalid.

For example, an email-address NameID format may be appropriate for certain integrations.

Example Output

Result of: NameIDFormatCommand

✓ urn:oasis:names:tc:SAML:2.0:nameid-format:transient

❌ urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

❌ urn:mace:shibboleth:1.0:nameIdentifier

These results indicate what the metadata advertises relative to the tool's checklist.

Troubleshooting NameID Compatibility

When a Service Provider cannot accept an Identity Provider's subject identifier:

  1. Inspect advertised NameID formats.
  2. Review the Service Provider's requirements.
  3. Confirm the Identity Provider can issue a compatible format.
  4. Check the configured subject identifier source.
  5. Review relevant SAML assertions and federation logs.

Common Misinterpretations

Every Format Must Be Present

False. The required formats depend on the integration.

Additional Formats Are Invalid

False. The checker labels unrecognized formats relative to its small predefined list.

Advertised Format Guarantees Runtime Behavior

Not necessarily. Runtime behavior also depends on configuration, policy, and authentication context.

Recommended Use

Use the bindings and NameID checks to identify potential interoperability differences.

Confirm actual requirements against the intended federation profile and participating systems.

Important: These commands provide metadata coverage checks, not full SAML standards validation.


Did this page help you?