| name | saml-sso-basics |
| description | High-level authorized assessment of SAML SSO misconfigurations: signature validation, assertion/response signing, audience restriction, ACS URL handling, and related SP/IdP trust issues. Use when enterprise SAML login, Assertion Consumer Service, or SAMLResponse parameters appear in scope. |
SAML SSO Basics (Authorized Assessment)
High-level methodology for SAML 2.0 service-provider (SP) and in-scope identity-provider (IdP) integrations. Focus: signature trust, audience, ACS, and assertion acceptance — not a full cryptographic break toolkit.
Use When
| Situation | Direction |
|---|
| App offers SAML SSO, enterprise login, or “Login with company IdP” | This skill |
Traffic shows SAMLRequest, SAMLResponse, RelayState, ACS endpoints | This skill |
Need SP checklist: signature required?, Audience/Recipient, destination | This skill |
| OAuth/OIDC “Sign in with…” (not SAML) | oauth-oidc-misconfiguration |
| JWT access tokens after SSO, without SAML XML issues | api-auth-and-jwt-abuse |
| Cookie session not rotated after SAML ACS | session-fixation-management |
| Multi-vector ATO including SAML as one surface | account-takeover-methodology + this for SAML depth |
| Attacking commercial SaaS IdP production outside engagement | Out of scope |
Keywords: SAML, SSO, ACS, Assertion Consumer Service, SAMLResponse, IdP metadata, EntityID, Audience, Signature wrapping (awareness), unsigned assertion.
Scope And Authorization
- Authorized assessments only: owned apps, labs, CTFs, or written engagement scope that names the SP and any IdP/tenant you may test.
- Prefer test IdP or customer-authorized staging IdP. Do not attack third-party IdP production (Okta, Azure AD, Google, etc.) beyond the SP’s configuration mistakes and any IdP app explicitly in scope.
- Use dual test identities (IdP user V and attacker-controlled IdP user A) when federation allows. Never replay stolen production assertions from real employees.
- Treat
SAMLResponse, assertions, session cookies, and metadata signing keys as secrets: redact; store offline; do not publish raw Base64 responses with live signatures in public write-ups.
- This skill is assessment methodology. Do not use it to deploy persistent backdoors, mass-create IdP users, or disrupt production SSO for all employees.
- XML signature crypto research beyond configuration flaws (e.g. novel CVE exploit development against third-party products) needs separate authorization and is outside this basics skill.
Core Model
User → IdP authenticates → IdP issues SAML Response/Assertion
→ Browser POST/Redirect to SP ACS
→ SP validates signature, conditions, audience, recipient/destination
→ SP establishes local session for NameID / attributes
| Trust control | Failure mode (high-level) | Impact class |
|---|
| Signature on Response and/or Assertion | Accept unsigned or partially signed; sign wrong node | Forge identity → ATO |
| Signing key / cert trust | Trust any cert in message; weak metadata import | Attacker signs as “IdP” |
Audience (AudienceRestriction) | Missing or wrong EntityID accepted | Token confusion / cross-SP |
| Recipient / Destination / ACS | Assertion accepted at wrong ACS or open redirect-like ACS | Cross-app or token theft |
Conditions time (NotBefore/NotOnOrAfter) | No skew check; infinite validity | Replay |
| Subject confirmation | Bearer conf without binding checks where required | Replay / mix-up |
| NameID / attributes | SP trusts mutable attrs for authZ without provisioning rules | Privilege confusion |
| RelayState | Open redirect after SSO | Post-login phishing hop |
Good proof: Controlled mutation of an in-scope SAML flow yields SP session as a principal you should not obtain (e.g. unsigned assertion accepted for V; audience for SP-B accepted on SP-A), with request/response evidence.
Bad proof: “SAML exists”; missing HTTP-only flags alone; theoretical wrapping without SP accepting a crafted message you demonstrated in lab/scope.
Workflow
1. Map the SAML deployment
Record:
| Field | Capture |
|---|
| SP EntityID | From metadata or config UI |
| ACS URLs | HTTP-POST and HTTP-Redirect bindings |
| IdP EntityID / SSO URL | In-scope IdP only |
| Metadata source | Static XML, URL fetch, vendor UI |
| What is signed | Response, Assertion, both; encrypted assertion? |
| NameID format | email, persistent, transient |
| Attribute → role mapping | groups, admin flags |
| SP session | cookie name; regenerate on ACS? |
Download SP metadata and IdP metadata only from authorized endpoints. Note WantAssertionsSigned, signing certs, and ACS list.
Typical browser trace:
GET /saml/login → redirect to IdP SSO with SAMLRequest
POST IdP login
POST SP ACS SAMLResponse=...&RelayState=...
Set-Cookie: session=...
Decode SAMLRequest/SAMLResponse (Base64, often deflated for Redirect binding) in a local tool or Burp SAML extension — offline, on copies of traffic you are allowed to capture.
2. Baseline happy path
- Complete SSO as test user V.
- Save raw ACS POST (redact later).
- Confirm local session identity (email, user id).
- Note whether a pre-ACS anonymous cookie is rotated (
session-fixation-management if not).
3. Signature validation (primary)
High-level tests against the SP (authorized lab/staging preferred):
| Probe | Idea | Expected secure behavior |
|---|
| Strip signature | Remove ds:Signature from Response/Assertion | Reject |
| Strip assertion sig only | Response signed, assertion unsigned (if SP wants assertion signed) | Reject if policy requires assertion sig |
| Empty signature / broken digest | Corrupt DigestValue or SignatureValue | Reject |
| Comment / whitespace tweaks | XML same-doc variations | Still validate correctly or reject; no auth bypass |
| Re-sign with attacker cert | Embed attacker KeyInfo and signature | Reject unless SP pins IdP cert from metadata |
| Partial signing | Sign outer Response but alter unsigned Assertion (if only response checked poorly) | Must not accept altered subject |
Document exactly which element the SP requires signed. Many real bugs are “signature present anywhere” or “verify signature but parse different node than verified” (signature wrapping awareness):
- Awareness only: classic wrapping places a signed assertion alongside an unsigned malicious assertion; broken SP verifies one and loads the other.
- In authorized tests, use established lab payloads or carefully controlled duplicates only on systems you may test; prove with dual NameIDs (benign signed vs attacker-controlled).
- Do not claim wrapping without showing SP session attributes match the unverified node.
If encryption (EncryptedAssertion) is used, note whether SP decrypts then skips signature checks — still require signature on enclosing response or decrypted assertion per deployment policy.
4. Audience restriction
Inspect AudienceRestriction / Audience in the assertion:
| Probe | Idea |
|---|
| Missing Audience | SP accepts any? |
| Wrong Audience | EntityID of another app or attacker value |
| Multiple Audience values | SP checks only first; include both legit and foreign |
| Typo / trailing slash / HTTP vs HTTPS EntityID | Parser mismatch |
Secure baseline: SP requires Audience to match this SP’s EntityID (exact, per metadata).
Finding: SP accepts assertion minted for another audience or with audience omitted → cross-service token acceptance risk (severity depends on who can obtain such assertions — usually needs compromised/evil IdP app registration or multi-SP IdP abuse in scope).
5. ACS, Destination, and Recipient
| Control | Where | Test |
|---|
| ACS URL | Where browser sends SAMLResponse | Can Response be POSTed to a different path/host still processed? |
| Destination | Response attribute | Mismatch with actual ACS — should fail |
| Recipient | SubjectConfirmationData | Should match ACS |
| ACS open redirect | Registration of ACS in IdP | If SP allows ACS on attacker host via config flaw, codes/assertions go to attacker |
Probes (authorized):
- Replay valid
SAMLResponse to alternate path on same host (/saml/acs vs /saml/acs2).
- Change Host/XFH only if Host skill is in scope — SP must not trust client Host for Audience/ACS decisions (
http-host-header-attacks helper).
- Confirm IdP-registered ACS list is exact match (no subdomain or path prefix wildcards you control).
6. Replay, lifetime, and binding
| Check | Action |
|---|
| Replay | Resubmit same SAMLResponse to ACS; second should fail (one-time) if SP tracks IDs |
| Expired | Wait or adjust NotOnOrAfter (re-sign only if you control IdP signing in lab) |
| InResponseTo | Missing/wrong correlation to SAMLRequest id |
| HTTP-Redirect vs POST | Large responses; tampering visibility |
| RelayState | RelayState=https://attacker.tld/ |
Do not brute-force or spam ACS in production; one replay pair is enough evidence.
7. NameID, attributes, and provisioning
After a valid signature path (or if SP skips signature — critical):
| Risk | Test (authorized dual users) |
|---|
| Attribute injection | If you control IdP attributes for A, set admin=true / groups |
| NameID change on re-login | Persistent vs email NameID account linking |
| Unsigned attr statement | Attrs outside signed assertion |
| Account linking | SAML email matches local user |
8. Metadata and SP configuration hygiene
| Area | What to verify |
|---|
| IdP cert pin | SP stores IdP signing cert from trusted metadata import — not “any KeyInfo” |
| Metadata URL fetch | If SP fetches IdP metadata by URL, SSRF risk → ssrf-server-side-request-forgery |
| TLS to IdP | Metadata and SSO over HTTPS |
| Dual control | Admin UI to upload new IdP cert requires strong auth (admin ATO is separate) |
| Logout (SLO) | Optional; signed LogoutRequest validation if exposed |
9. Session establishment after ACS
- Compare session cookie pre- and post-ACS (
session-fixation-management).
- Map SP session user to assertion NameID — mismatch is a finding.
- If SP mints JWT after SAML, validate JWT path with
api-auth-and-jwt-abuse separately.
- CSRF on “link SAML to account” while password session active →
csrf-cross-site-request-forgery.
10. Remediation guidance (report-ready)
Pair implementation notes with code-quality-standards where SP code is in scope:
- Require cryptographic signature on Assertion (and Response per policy); verify using pinned IdP certificates from trusted metadata — ignore untrusted
KeyInfo.
- Validate Audience = SP EntityID; Destination/Recipient = this ACS URL; enforce
NotBefore/NotOnOrAfter with small skew; enforce one-time assertion IDs.
- Parse XML with a SAML-aware, XXE-safe stack; never deserialize untrusted DTD (
xxe-xml-external-entity if XML parser is loose).
- Use well-maintained SAML libraries; keep wrapping-relevant patches current.
- Exact-match ACS registration at IdP; no attacker-controlled ACS.
- Regenerate SP session on successful SSO; invalidate on logout.
- Treat attribute-based roles carefully; admin elevation only from trusted claim allowlists.
- Prefer separate EntityIDs per environment (dev/stage/prod) to reduce cross-env assertion reuse.
Routing
| Need | Skill |
|---|
| SAML signature, audience, ACS, assertion acceptance (this surface) | This skill |
| OAuth / OIDC (not SAML) | oauth-oidc-misconfiguration |
| JWT minted after or instead of SAML | api-auth-and-jwt-abuse |
| SP session fixation at ACS | session-fixation-management |
| Multi-vector ATO planning including SAML | account-takeover-methodology |
| Password-reset path parallel to SSO | password-reset-poisoning |
| IDOR after SSO session | idor-broken-object-authorization |
| RelayState open redirect | open-redirect |
| Metadata URL SSRF | ssrf-server-side-request-forgery |
| XXE via SAML XML parser | xxe-xml-external-entity |
| Host header confuses ACS base URL | http-host-header-attacks |
| Secure SP implementation review | code-quality-standards |
Checklist
Rules
- Authorized only. SP misconfig and in-scope IdP apps — not opportunistic attacks on global IdP infrastructure.
- High-level SAML assessment: prefer configuration and acceptance-logic flaws over unpublished crypto exploits.
- Dual-account or lab IdP proofs only; never weaponize against real workforce identities.
- Signature wrapping claims need demonstrate-able SP acceptance of the unverified identity node.
- Distinguish SAML issues (this skill) from OAuth/OIDC (
oauth-oidc-misconfiguration) and pure JWT API flaws (api-auth-and-jwt-abuse).
- Decode and mutate copies of messages locally; avoid pasting live
SAMLResponse blobs into public issues.
- If SSO succeeds securely, say so — a clean negative result is valuable.
Note
Basics skill for SAML SSO misconfiguration on authorized targets. For full identity-takeover prioritization across reset, session, OAuth, JWT, and IDOR, use account-takeover-methodology as orchestrator.
