SAML: Fundamentals, Use Cases, Exploits, and Best Practices

Security Assertion Markup Language (SAML) is an XML-based framework for transmitting authentication and authorization data between an identity provider (IdP) and a service provider (SP). It’s widely used in Single Sign-On (SSO) implementations, allowing users to authenticate once and access multiple applications without repeatedly entering credentials.

In this blog, we’ll explore the fundamentals of SAML, the SAML authentication workflow, the potential security weaknesses, and provide code-level examples of common SAML vulnerabilities, as well as best practices for securing SAML implementations.


What is SAML?

SAML (Security Assertion Markup Language) is an open standard that allows identity providers (IdPs) and service providers (SPs) to exchange authentication and authorization information. SAML assertions provide a secure means for an identity provider to authenticate users and transmit user attributes or roles to a service provider.

SAML is often used in Single Sign-On (SSO) scenarios, where a user logs in once via the IdP and can then access multiple services (SPs) without needing to re-authenticate.


Basic SAML Terminology

  1. Identity Provider (IdP): The entity that authenticates users and issues SAML assertions.
  2. Service Provider (SP): The entity that receives and validates SAML assertions.
  3. SAML Assertion: The statement issued by the IdP that contains information about a user.
  4. SAML Request: A request made by the SP to the IdP asking for user authentication.
  5. SAML Response: The response from the IdP containing the SAML assertion with authentication results.

SAML Authentication Workflow

The SAML authentication process follows these steps:

  1. User Requests Access: The user attempts to access a resource from the SP.
  2. SP Sends Authentication Request: The SP sends a SAML authentication request to the IdP (via HTTP redirect or POST).
  3. IdP Authenticates User: The IdP authenticates the user (using credentials, multi-factor authentication, etc.).
  4. IdP Sends SAML Response: After successful authentication, the IdP sends a SAML response back to the SP.
  5. SP Verifies the Assertion: The SP verifies the signature of the SAML response. If the signature is valid, the user gains access to the requested resource.

SAML Request Example (XML Format)

Here is a basic example of a SAML authentication request sent from the SP to the IdP:

<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://sp.example.com/SAML/ACS"
Destination="https://idp.example.com/SAML/SSO"
ID="12345"
IssueInstant="2024-12-23T12:00:00Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Version="2.0">

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.example.com</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" AllowCreate="true"/>
</samlp:AuthnRequest>


Weak Points and Exploits in SAML

While SAML is a secure protocol, there are several potential vulnerabilities that attackers can exploit. Here are some of the most common weaknesses, along with examples and mitigations.

1. Message Expiration (Replay Attacks)

SAML assertions should have an expiration time to prevent replay attacks. If an assertion is valid for too long, attackers may intercept and replay it to gain unauthorized access.

Example Exploit: An attacker could capture a valid SAML response and replay it after expiration or with altered timestamps.

Mitigation: Always set a short expiration time for SAML assertions, and synchronize clocks between IdP and SP.

Here’s how to set an expiration time for a SAML assertion:

<saml:Conditions NotBefore="2024-12-23T12:00:00Z" NotOnOrAfter="2024-12-23T12:30:00Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>

The NotOnOrAfter and NotBefore attributes define the valid time window for the assertion.


2. SAML Response Forwarding (Assertion Reuse)

SAML responses can be forwarded from one SP to another. Attackers can intercept a valid response and forward it to an unauthorized SP.

Example Exploit: An attacker could forward a valid SAML response from a trusted IdP to an unauthorized SP, granting them unauthorized access.

Mitigation: Implement audience restrictions in the SAML assertion to ensure that the response is only accepted by the intended SP.

<saml:Conditions>
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>

This ensures the assertion is only valid for the https://sp.example.com service provider.


3. Flawed Signature Validation Mechanism

Some systems may not validate the entire SAML message or may use weak signing algorithms, making them susceptible to signature forgery.

Example Exploit: An attacker could forge a SAML assertion and send it to the SP without being detected, as the signature is not properly validated.

Mitigation: Ensure the SAML signature is verified using strong algorithms such as RSA-SHA256. All parts of the SAML assertion, including the issuer, conditions, and the entire response, should be validated.


4. Signature Not Verified

Some implementations may not enforce signature verification, leading to unauthorized access with unsigned assertions.

Example Exploit: An attacker could send an unsigned SAML assertion to the SP, bypassing the authentication process.

Mitigation: Enforce strict signature verification for every SAML response, even if the signature is optional in certain configurations.


5. XML Signature Wrapping (XSW) Attack

XML Signature Wrapping attacks involve altering the SAML assertion while keeping the signature valid. The attacker can inject malicious elements that are not covered by the signature.

Example Exploit: The attacker sends a SAML response with a valid signature but alters the content of the assertion by wrapping it in additional XML tags.

Mitigation: Ensure that all XML elements within the SAML response are covered by the signature. Avoid allowing elements to be outside of the signed content.

<samlp:Response ID="response123" Destination="https://sp.example.com/acs">
<saml:Assertion>
<!-- Original assertion content here -->
</saml:Assertion>
</samlp:Response>

Best Practices for Securing SAML Implementations

To prevent these vulnerabilities, follow these best practices:

  1. Strict Signature Validation: Always verify the SAML assertion signature using strong cryptographic algorithms (e.g., RSA-SHA256).
  2. Use Audience Restrictions: Ensure the SAML response is only valid for the intended service provider.
  3. Time-Based Expiry: Set reasonable expiration times for SAML assertions and ensure proper clock synchronization.
  4. Secure Transmission: Always use HTTPS to prevent interception of sensitive SAML data.
  5. Validate Inputs: Ensure proper validation of XML inputs to avoid attacks like XXE or XML Signature Wrapping.
  6. Regular Audits: Periodically audit SAML assertions, responses, and overall configurations for vulnerabilities.

Conclusion

SAML is a powerful protocol used to simplify authentication and enable Single Sign-On (SSO) between different services. However, if not implemented properly, it opens up a range of security vulnerabilities. By understanding common attacks such as signature verification flaws, XML wrapping, and replay attacks, organizations can strengthen their SAML security measures. Following best practices like enforcing strong signature validation, using audience restrictions, and regularly auditing configurations will help protect against common SAML-based exploits.