Saml Basics

SAML Basics

What is SAML

Security Assertion Markup Language (SAML) enables identity providers (IdP) to send authorization credentials to service providers (SP), facilitating single sign-on (SSO). This approach simplifies managing multiple logins by allowing a single set of credentials across multiple websites.

SAML leverages XML for standardized communication between IdPs and SPs, linking user identity authentication with service authorization.

SAML vs OAuth

• SAML: Tailored for enterprise SSO login security control
• OAuth: Mobile-friendly, uses JSON, collaborative effort from companies like Google and Twitter

SAML Authentication Flow

The SAML authentication process follows these steps:

1. Resource Access Attempt: User tries to access a protected resource
2. SAML Request Generation: SP doesn't recognize the user and generates a SAML Request
3. Redirect to IdP: User is redirected to the IdP with the SAML Request passing through the browser
4. IdP Receives Request: IdP receives the SAML Request
5. Authentication at IdP: IdP authenticates the user
6. User Validation: IdP validates the user's legitimacy to access the requested resource
7. SAML Response Creation: IdP generates a SAML Response containing necessary assertions
8. Redirect to SP's ACS URL: User is redirected to the SP's Assertion Consumer Service (ACS) URL
9. SAML Response Validation: ACS validates the SAML Response
10. Resource Access Granted: Access to the initially requested resource is granted

Analyzing SAML Requests

When a user requests access to a secure resource, the SP generates a SAML Request. The raw SAML Request is XML:

<?xml version="1.0"?>
<samlp:AuthnRequest
  AssertionConsumerServiceURL="https://shibdemo-sp1.test.edu/acs"
  Destination="https://idp.example.com/saml"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  ID="_request-id"
  IssueInstant="2024-01-15T10:30:00Z">
  <saml:Issuer>https://shibdemo-sp1.test.edu</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>

Key SAML Request Elements

• AssertionConsumerServiceURL: Where the IdP should send the SAML Response post-authentication
• Destination: The IdP's address to which the request is sent
• ProtocolBinding: Defines the transmission method of SAML protocol messages
• saml:Issuer: Identifies the entity that initiated the request

SAML Request Transmission

After SAML Request generation, the SP responds with a 302 redirect, directing the browser to the IdP with the SAML Request encoded in the HTTP response's Location header:

• RelayState: Maintains state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response
• SAMLRequest: A compressed and encoded version of the raw XML, utilizing Deflate compression and base64 encoding

Analyzing SAML Responses

The SAML Response contains several key components:

<samlp:Response
  ID="_response-id"
  Version="2.0"
  IssueInstant="2024-01-15T10:30:05Z"
  Destination="https://shibdemo-sp1.test.edu/acs">
  
  <ds:Signature>
    <!-- XML Signature for message integrity -->
  </ds:Signature>
  
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  
  <saml:Assertion ID="_assertion-id">
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        user@example.com
      </saml:NameID>
    </saml:Subject>
    
    <saml:Conditions NotBefore="2024-01-15T10:30:00Z" NotOnOrAfter="2024-01-15T11:30:00Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://shibdemo-sp1.test.edu</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    
    <saml:AuthnStatement AuthnInstant="2024-01-15T10:30:00Z">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    
    <saml:AttributeStatement>
      <saml:Attribute Name="email">
        <saml:AttributeValue>user@example.com</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
    
    <ds:Signature>
      <!-- XML Signature for assertion -->
    </ds:Signature>
  </saml:Assertion>
</samlp:Response>

Key SAML Response Elements

• ds:Signature: XML Signature ensuring integrity and authenticity of the issuer. SAML responses often contain two ds:Signature elements - one for the message and one for the assertion
• saml:Assertion: Holds information about the user's identity and possibly other attributes
• saml:Subject: Specifies the principal subject of all statements in the assertion
• saml:StatusCode: Represents the status of the operation in response to the corresponding request
• saml:Conditions: Details conditions like validity timing of the Assertion and the specified Service Provider
• saml:AuthnStatement: Confirms that the IdP authenticated the subject of the Assertion
• saml:AttributeStatement: Contains attributes describing the subject of the Assertion

SAML Response Transmission

Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes:

• RelayState: State parameter
• SAMLResponse: The encoded SAML Response

The ACS is responsible for processing and validating the SAML Response. After validation, access is granted to the protected resource.

XML Signatures in SAML

XML Signatures are versatile, capable of signing an entire XML tree or specific elements within it. They can be applied to any XML Object, not just Response elements.

Basic XML Signature Structure

<Signature>
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="#assertion-id">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue>base64-encoded-digest</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>base64-encoded-signature</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509Certificate>base64-encoded-certificate</X509Certificate>
    </X509Data>
  </KeyInfo>
  <Object/>
</Signature>

Each Reference element signifies a specific resource being signed, identifiable by the URI attribute.

Types of XML Signatures

1. Enveloped Signature

The signature is a descendant of the resource it signs, contained within the same XML structure as the signed content.

<samlp:Response ID="_response-id">
  ...
  <ds:Signature>
    <ds:SignedInfo>
      ...
      <ds:Reference URI="#_response-id">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        </ds:Transforms>
      </ds:Reference>
    </ds:SignedInfo>
  </ds:Signature>
  ...
</samlp:Response>

The ds:Transform element specifies that it's enveloped through the enveloped-signature algorithm.

2. Enveloping Signature

The signature wraps the resource being signed.

<ds:Signature>
  <ds:SignedInfo>
    ...
    <ds:Reference URI="#_response-id">
      ...
    </ds:Reference>
  </ds:SignedInfo>
  <samlp:Response ID="_response-id">
    ...
  </samlp:Response>
</ds:Signature>

3. Detached Signature

The signature is separate from the content it signs. The signature and content exist independently, but a link between them is maintained.

<samlp:Response ID="_response-id">
  ...
</samlp:Response>
<ds:Signature>
  <ds:SignedInfo>
    ...
    <ds:Reference URI="#_response-id">
      ...
    </ds:Reference>
  </ds:SignedInfo>
</ds:Signature>

Security Testing Considerations

When analyzing SAML implementations for security testing:

1. Decode SAMLRequest/SAMLResponse parameters: These are Deflate-compressed and base64-encoded
2. Validate XML signatures: Check if signatures are properly verified by the SP
3. Examine signature types: Different signature types have different security implications
4. Check assertion conditions: Look at NotBefore, NotOnOrAfter, and AudienceRestriction elements
5. Review attribute statements: These may contain sensitive user information
6. Analyze the ACS endpoint: This is where SAML responses are processed and validated

References

• How to Test SAML - A Methodology