As we wrap up the SAML module, we shift from attacking to defending. A secure SAML implementation isn't just about the protocol; it's about the operational lifecycle of keys, metadata, and session management.
The metadata file is the 'Source of Truth.' If an attacker can trick an SP into importing a malicious metadata file, they can essentially tell the SP to trust a rogue IdP they control.
💡 Always use signed metadata or secure a direct HTTPS channel for metadata exchange. Never accept metadata via email or plaintext uploads without verification.
The command above demonstrates how to verify the integrity of the metadata file using the provider's public key before importing it into the SP.
The most common cause of SAML outages is an expired signing certificate. However, the most common cause of SAML breaches is a leaked signing key.
# Typical key rotation strategy
# 1. IdP generates a new key pair
# 2. IdP adds NEW public key to metadata (keeping OLD one)
# 3. SP imports updated metadata (now trusts both keys)
# 4. IdP switches to signing with NEW key
# 5. IdP removes OLD key from metadata| Setting | Weak Configuration | Secure Configuration |
|---|---|---|
| Assertion Signing | Disabled/Optional | Mandatory |
| SAML Response Signing | Disabled | Mandatory |
| Assertion Encryption | Plaintext | Encrypted (using SP public key) |
| Timestamp Validation | Disabled/Loose | Strict (max 5 min skew) |
| Redirect URIs | Wildcard / Partial | Exact Match |
Single Log-Out (SLO) is the most difficult part of SAML to implement. When a user logs out of the IdP, the IdP must notify every SP the user accessed so they can terminate their local sessions.
SAML is a 'Point-in-Time' authentication. If a user is fired and their account is disabled in the IdP, they may still have an active session at the SP until the local session expires.
Verify exercises to earn ★ 200 XP and unlock next lab level.