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
- Select Check SAML Bindings.
- Upload a SAML metadata XML file.
- Click Execute Command.
- Review the binding coverage report.
Binding Types Checked
ShibbDebugger checks for five predefined bindings.
| Binding | Purpose Described by the Tool |
|---|---|
| HTTP-Redirect | Login and logout requests |
| HTTP-POST | SSO message transport |
| HTTP-POST-SimpleSign | Alternative signed POST transport |
| SOAP | Attribute or artifact resolution |
| SAML 1.0 SOAP | Legacy SAML 1.x interoperability |
Exact Binding Identifiers
HTTP-Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-RedirectHTTP-POST
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POSTHTTP-POST-SimpleSign
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSignSOAP
urn:oasis:names:tc:SAML:2.0:bindings:SOAPSAML 1.x SOAP
urn:oasis:names:tc:SAML:1.0:bindings:SOAP-bindingServices 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:SOAPImportant 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
- Select Check NameID Formats.
- Upload a SAML metadata XML file.
- Click Execute Command.
- Review the detected NameID formats.
Formats Checked
ShibbDebugger checks the presence of three predefined identifiers.
| Format | Meaning |
|---|---|
| Transient | Short-lived subject identifier |
| Persistent | Stable subject identifier scoped to federation relationships |
| Shibboleth 1.x NameIdentifier | Legacy identifier format |
Transient
urn:oasis:names:tc:SAML:2.0:nameid-format:transientTransient 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:persistentPersistent identifiers support stable subject recognition across multiple sessions under the relevant federation model.
Legacy Shibboleth Identifier
urn:mace:shibboleth:1.0:nameIdentifierThis 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:nameIdentifierThese 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:
- Inspect advertised NameID formats.
- Review the Service Provider's requirements.
- Confirm the Identity Provider can issue a compatible format.
- Check the configured subject identifier source.
- 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.
Updated 8 days ago
