SAML SSO - VAPT

saml_vapt_checklist.md

🛡️ SAML SSO - Flow, Parameters, and VAPT Checklist

SAML is primarily used for single sign-on (SSO) and authentication within enterprise environments

🔄 SAML SSO Flow – SP-Initiated (Typical)

1. User Requests Resource (SP)

• User tries to access a protected page.
• SP generates a SAMLRequest and redirects to IdP.

2. SAML AuthnRequest (SP → IdP)

• HTTP Method: GET (Redirect Binding)
• Parameters:
  • SAMLRequest: Base64+DEFLATE encoded XML AuthnRequest
  • RelayState: Optional state (e.g. return URL)
• Inside AuthnRequest XML:
  • Issuer: SP Entity ID
  • ID: Unique identifier
  • IssueInstant: Timestamp
  • Destination: IdP SSO URL
  • AssertionConsumerServiceURL: Where IdP should send response
  • NameIDPolicy: Format of user identity
  • ForceAuthn: Force reauthentication

3. User Authenticates with IdP

• Google Workspace prompts login or uses existing session.

4. SAML Response (IdP → SP)

• HTTP Method: POST (Browser auto-submits form)
• Form Fields:
  • SAMLResponse: Base64-encoded, signed XML response
  • RelayState: (if present in request)
• Inside SAML Response:
  • <saml:Assertion>:
    • Issuer: IdP Entity ID
    • Subject: Includes NameID
    • Conditions:
      • NotBefore, NotOnOrAfter
      • AudienceRestriction → SP Entity ID
    • AttributeStatement: Contains user attributes like email, groups
    • Signature: Ensures authenticity

5. SP Validates Response and Establishes Session

• Checks signature, timestamps, audience, and user attributes.

---

📦 Important SAML Parameters

Parameter	Location	Purpose
SAMLRequest	Redirect URL	Encoded AuthnRequest from SP
RelayState	Redirect URL & POST	SP-specific state value
SAMLResponse	POST Form	Encoded signed XML Assertion from IdP
NameID	Inside <Subject>	User identity (email, etc.)
Audience	Inside <Conditions>	Valid SP audience (must match SP)
NotBefore, NotOnOrAfter	Inside <Conditions>	Validity time window
AttributeStatement	Inside <Assertion>	Custom user data (e.g. groups, roles)

---

✅ SAML VAPT Checklist

🔐 Signature & Assertion Validation

• Is the SAMLResponse signature verified?
• Does SP enforce Audience matching?
• Are NotBefore and NotOnOrAfter validated correctly?
• Is the Issuer checked against trusted IdPs?

🎯 RelayState and Redirect Attacks

• Can RelayState be used for open redirect?
• Does SP validate trusted redirect URLs?

🧬 Assertion Tampering

• Can you alter groups or email in Assertion and replay?
• Does SP verify the signature of the assertion itself?

🛡️ Replay & Expired Assertion Use

• Can a valid SAMLResponse be reused?
• Is a unique InResponseTo ID validated?

⚠️ Metadata / IdP Misconfig

• Can you register or inject a malicious IdP?
• Does the SP consume only known, static IdP metadata?

🧪 Binding Confusion

• Does SP support both POST and Redirect bindings?
• Can you abuse inconsistent handling between bindings?

---

📚 Tools for Testing

• Burp Suite + SAML plugins (e.g., SAML Raider)
• samltool.io / SAMLTracer browser extension
• xmlsec1 – CLI for validating XML signatures
• jwt.io – Though not for SAML, for JWT-based OIDC checks

---

✅ Best Practices for SP Developers

• Always verify signatures and audience
• Use strict time validation (NotBefore, NotOnOrAfter)
• Never trust user attributes unless assertion is verified
• Use signed assertions and responses (WantAssertionsSigned=true)
• Log and alert on replayed or malformed assertions