SAML & Federation

Most important commands to remember

• xmllint --noout — check whether the metadata parses as XML.
• xmllint --format — make the metadata structure easier to inspect.

Commands and flags

Command or option	Meaning
--nonet	Disable network resource retrieval in libxml2 versions that provide it.
--noout	Suppress the parsed document; syntax errors still appear.
--format	Print an indented representation without changing the source file.
idp-metadata.xml	A trusted local metadata export, not a captured user’s login assertion.

Newer libxml2 versions have removed built-in network fetching, making --nonet unnecessary there. This command is a parser, not a sandbox or a SAML signature verifier.

The concepts that matter

1. Federation moves authentication across a trust boundary

In federation, an application accepts an authentication statement from an external identity provider. In SAML terminology, the application is a service provider, or SP, and the authentication authority is an identity provider, or IdP.

The SP trusts a configured IdP for a defined purpose. That agreement can simplify sign-in across organizations, but it does not make every identity or group from the other organization automatically authorized for every local action.

2. An assertion carries statements about a subject

A SAML assertion is XML containing statements such as who authenticated, under what conditions, and possibly additional attributes. A browser-based sign-in commonly transports a response from the IdP to the SP’s assertion consumer service.

The browser carries the message but is not the authority that makes it trustworthy. The SP must process the response using the expected binding and profile. XML that looks plausible is still untrusted input until the required validations succeed.

3. Metadata describes the federation partners

Metadata identifies an entity and advertises roles, endpoints, supported bindings, and keys. An entity identifier is a name in the federation; it is not necessarily a URL that you visit to sign in.

Signing certificates in metadata help configure message verification. They are not interchangeable with the HTTPS certificate of the login website. Trustworthy metadata distribution and planned signing-key rollover keep the partnership working as keys change.

4. Signature verification must be tied to the accepted assertion

An SP validates the relevant signature using trusted keys and processes the exact signed content. It also checks issuer, audience, destination or recipient as applicable, time conditions, and request correlation when the flow requires it. Replay handling prevents reuse of an already accepted assertion.

Well-formed XML is only the first parsing step. It proves neither a valid signature nor permission to create a session. Use a maintained SAML implementation: manually finding a familiar username in the XML skips the essential trust checks.

One small example

Optional: place a trusted test IdP metadata export in the current directory under the stated filename. Use metadata rather than a real user’s assertion, which can contain personal information and usable authentication material.

xmllint --nonet --noout idp-metadata.xml
xmllint --nonet --format idp-metadata.xml

The first command should produce no output if the file is well-formed XML. The second should make elements such as EntityDescriptor, IDPSSODescriptor, KeyDescriptor, and SingleSignOnService easier to locate; namespace prefixes may differ. Compare the entity ID with the advertised endpoint locations and bindings.

No output from the parser is not successful SAML authentication or signature verification. The commands do not configure a federation partner, check certificate trust, or contact an endpoint. They leave the exported file unchanged.

Keep this idea: Federation works because the application validates a statement from a deliberately trusted issuer, not because the browser supplies an identity-shaped document.