Learning outcomes
- Identify SAML authority, identity provider, service provider, user agent, and metadata roles.
- Trace authentication request, response, assertion, binding, and local session.
- Validate signature, issuer, audience, recipient, time, correlation, and replay rules.
- Bound metadata rollover, account mapping, session, and logout failure.
Protocol roles
The user agent reaches a service provider. The service provider can send an authentication request to an identity provider. The identity provider authenticates the subject and returns a signed response or assertion through a defined browser binding. Metadata distributes entity identifiers, endpoints, keys, and supported bindings.
Message flow
- The service provider selects a trusted identity provider and creates a request identifier.
- The browser carries the request through the selected binding.
- The identity provider authenticates the user and issues a response for the service provider.
- The service provider validates the response and assertion before creating a local session.
- Application authorization uses mapped local identity and attributes.
Validation and failure cases
Validate XML signature according to the profile, trusted issuer, destination and recipient, audience, time conditions, request correlation, subject confirmation, allowed binding, and replay. Reject unsigned or ambiguously signed structures, duplicate identifiers, wrong audience, unsolicited responses when not allowed, and stale metadata. Keep issuer plus stable subject distinct from email.
Logout can involve identity-provider and service-provider sessions, browser redirects, and partial failure. It does not guarantee that every application or token session ended.
Design tradeoffs and residual risk
Signed metadata and rollover improve trust agility and require overlap and cache discipline. Unsolicited sign-in reduces state and correlation. Broad attribute release simplifies applications and increases exposure and stale authorization risk.
Residual risk includes compromised issuer keys, XML library defects, unsafe account linking, application sessions after logout, and weak recovery at the identity provider.
Pomerium boundary
Pomerium behavior depends on the configured identity-provider integration and supported federation path. Operators own identity-provider metadata, signing trust, subject mapping, attribute authority, local lifecycle, and application sessions. Validate current product support rather than assuming every SAML profile is implemented.
Exercise
Capture a redacted test flow. Label entity identifiers, endpoints, request ID, response, assertion, subject, audience, recipient, conditions, signatures, and session creation. Mutate one security field at a time and verify rejection.
Evaluation checklist
- Are issuer, destination, recipient, audience, subject, time, and request correlation validated?
- Is signature validation bound to the expected profile and trusted metadata?
- Can XML ambiguity, replay, unsolicited response, or stale metadata succeed?
- Does account mapping use an issuer-scoped stable subject?
- Which sessions and credentials remain after logout?
Next learning unit
Security Assertion Markup Language (SAML)
Security Assertion Markup Language 2.0 exchanges authentication, attribute, and authorization decision assertions between federation parties.
