SAML — The Federated Trust Engine
SAML is an inter-domain authentication protocol that allows a Service Provider to trust a signed assertion issued by an Identity Provider.
Why SAML Exists
Kerberos is powerful inside a domain, but modern enterprise access does not stay inside one neat boundary. Users access SaaS platforms, partner systems, cloud services, and applications owned by different organizations.
The problem is simple: if a user wants to access a resource hosted by another organization, who should authenticate the user?
SAML solves this by allowing the Service Provider to trust an assertion issued by a trusted Identity Provider.
The SAML Trust Model
SAML stands for Security Assertion Markup Language. The important words are Security and Assertion. The Service Provider does not authenticate the user directly. Instead, it relies on an assertion issued by the Identity Provider.
This is similar to international travel. A country may not know a traveler personally, but it may trust the passport issued by the traveler’s home country.
Key players
- User: The person trying to access a protected resource.
- Browser: The user agent that carries redirects and SAML messages.
- Service Provider: The application the user wants to access.
- Identity Provider: The trusted system that authenticates the user and issues the assertion.
High-Level SAML Workflow
The user first attempts to access the Service Provider. The Service Provider realizes it does not have a valid local session for the user. It then generates a SAML Authentication Request and redirects the browser to the Identity Provider.
The Identity Provider authenticates the user. After successful authentication, it creates a SAML assertion, signs it using its private key, and sends it back to the Service Provider through the browser, typically to the Assertion Consumer Service endpoint.
User → Service Provider: Access Request
Service Provider → Browser: SAML AuthnRequest
Browser → Identity Provider: Redirect with AuthnRequest
Identity Provider → User: Authentication Workflow
Identity Provider → Browser: Signed SAML Response
Browser → Service Provider ACS: POST SAML Response
Service Provider → User: Session Created
The Assertion: Core Trust Artifact
The SAML assertion is the core trust artifact. It can include authentication statements, attribute statements, and authorization statements.
- Authentication Statement: Describes how and when the user authenticated.
- Attribute Statement: Carries user attributes such as name, email, or role.
- Authorization Statement: May describe permitted actions, though many systems rely on local SP authorization.
The most important part is the signature. The Identity Provider signs the assertion or the SAML response using its private key. The Service Provider validates the signature using the Identity Provider’s public key.
A secure SAML implementation must validate the exact signed object it consumes. Unsigned or attacker-injected assertion data must never be used to create a session.
What the Service Provider Must Validate
When the Service Provider receives the SAML response at the ACS endpoint, it must perform several checks before creating a session.
- Signature validation: Confirm the response or assertion was signed by the trusted Identity Provider.
- Audience validation: Confirm the assertion was meant for this Service Provider.
- Destination validation: Confirm the response was sent to the correct ACS endpoint.
- Replay protection: Reject reused assertion IDs.
- Time validity: Ensure the assertion is within its valid time window.
- Attribute handling: Map attributes to local roles safely and conservatively.
Where SAML Can Be Attacked
SAML is elegant, but weak implementation can create serious risk. Attackers often target the trust assumptions between the Identity Provider, browser, and Service Provider.
Common attack paths
- ACS URL manipulation: Redirecting the SAML response to an attacker-controlled endpoint.
- Golden SAML: Forging assertions after compromising the Identity Provider signing key.
- XML signature wrapping: Injecting malicious assertion data while the application validates the wrong signed object.
- Replay attacks: Reusing a valid assertion if replay checks are weak.
- Audience bypass: Using an assertion intended for one Service Provider against another.
- Stale or excessive attributes: Abusing outdated or over-privileged role mappings.
Defending SAML
SAML security depends on strict metadata, strong cryptographic validation, safe assertion handling, and Identity Provider hardening.
- Register strict ACS URLs and do not allow arbitrary redirect destinations.
- Use signed AuthnRequests where appropriate.
- Validate the exact signed XML object that will be consumed.
- Enforce short assertion validity windows.
- Implement replay checks using assertion IDs.
- Validate audience and destination fields strictly.
- Protect IdP signing keys using strong access control, HSM, KMS, or equivalent controls.
- Monitor abnormal assertion patterns, unusual federation activity, and suspicious login flows.
SAML becomes rock-solid when the Service Provider validates assertions strictly and the Identity Provider’s signing key is protected like a crown jewel.
Final Thought
SAML is an elegant authentication protocol for federated trust. It allows one system to trust another system’s authentication decision without sharing passwords across domains.
The next time you access an enterprise SaaS application and are redirected to your organization’s login page, remember what is happening behind the scenes: the application is not authenticating you directly. It is trusting a signed assertion from an Identity Provider it has agreed to trust.