Overview
SAML 2.0 (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between Identity Providers (IdPs) and Service Providers (SPs). For nearly two decades, SAML has been the dominant protocol for enterprise single sign-on, enabling users to authenticate once and access multiple applications without re-entering credentials. While SAML remains deeply embedded in enterprise environments—particularly for legacy applications and established SaaS integrations—it is increasingly considered a legacy protocol for new implementations. OpenID Connect (OIDC), built on OAuth 2.0, offers a more modern, JSON-based alternative better suited for mobile applications, APIs, and cloud-native architectures. Organizations should continue supporting SAML for existing integrations while choosing OIDC for new applications and developing migration strategies for long-term SAML deprecation.
Architecture & Reference Patterns
Pattern 1: SP-Initiated SSO
Users navigate directly to an application (SP), which redirects unauthenticated users to the IdP. The IdP authenticates the user and redirects back to the SP with a SAML assertion. Most common pattern—users can bookmark application URLs and access them directly. Requires SP to be configured with IdP metadata.
Pattern 2: IdP-Initiated SSO
Users start at an IdP portal and click application links. The IdP generates a SAML assertion and sends the user directly to the SP. Common with enterprise portals (Okta, Azure AD My Apps) but has security concerns—the assertion isn't bound to a specific request, potentially enabling replay attacks if not handled carefully.
Pattern 3: SAML as Federation Protocol
SAML federates identity between organizations, enabling users from Organization A's IdP to access Organization B's applications. Trust is established through metadata exchange; attributes are mapped between organizations. Common in B2B scenarios, academic federations (InCommon), and partner portals.
Pattern 4: SAML to OIDC Bridge
An identity broker accepts SAML assertions from the IdP and translates them to OIDC tokens for modern applications. Enables legacy IdPs (ADFS, older SAML-only providers) to work with OIDC applications. Useful during migration but introduces additional complexity and a potential failure point.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| New application protocol | SAML, OIDC | OIDC for all new applications | SAML only if the application exclusively supports it |
| IdP-initiated vs. SP-initiated | Both, SP-only, IdP-only | SP-initiated preferred for security | IdP-initiated has replay attack risks |
| Assertion signing | Signed assertions, signed + encrypted | Signed at minimum; add encryption for sensitive attributes | Unsigned assertions should never be accepted |
| NameID format | Persistent, transient, email, unspecified | Persistent for account linking; transient for privacy | Email-based NameID can change; use persistent where possible |
| Attribute release | All attributes, minimal, SP-specific | Minimal required per SP | Over-sharing creates privacy and security risks |
| SAML binding | HTTP POST, HTTP Redirect, both | HTTP POST for assertions (size limits on redirect) | Redirect is fine for requests but assertions are too large |
Implementation Approach
Phase 0: Discovery
Inputs: Application inventory, current SAML implementations, IdP capabilities, application requirements Outputs: SAML-dependent applications inventory, OIDC migration candidates, SAML configuration standards assessment, attribute requirements per SP
Phase 1: Design
Inputs: Discovery outputs, security requirements, federation requirements Outputs: SAML configuration standards document, metadata management procedures, attribute mapping specifications, certificate management design, OIDC migration roadmap
Phase 2: Build & Integrate
Inputs: Design documents, IdP access, SP applications, test users Outputs: IdP configured with SP metadata, pilot SPs integrated and tested, certificate rotation procedures validated, monitoring configured, documentation completed
Phase 3: Rollout
Inputs: Tested configuration, application migration plan, user communication Outputs: SPs migrated to standardized SAML configuration, legacy SAML implementations retired or upgraded, operational procedures documented, help desk trained
Phase 4: Operate
Inputs: Production SAML environment, monitoring, migration roadmap Outputs: Certificate rotations executed on schedule, SP metadata changes incorporated, OIDC migration progressing, federation relationships maintained, SAML deprecation timeline progressing
Deliverables
- SAML configuration standards document
- Metadata management procedures
- Attribute mapping specifications per SP
- Certificate management and rotation procedures
- OIDC migration roadmap
- Troubleshooting runbook for SAML issues
- SP onboarding checklist
- Federation trust documentation
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| Certificate expiration breaks SAML | H | H | Approaching expiration dates, missed renewals | Automated monitoring, 90/30/7 day alerts, rotation procedures |
| XML vulnerabilities (XXE, signature wrapping) | M | H | Security assessment findings, CVEs | Use vetted SAML libraries, security testing, keep libraries updated |
| Metadata synchronization failures | M | M | Authentication failures after changes, SP not recognizing IdP | Automated metadata refresh, monitoring, manual sync procedures |
| Attribute mismatch causes authorization failures | M | M | Users lacking expected access, support tickets | Thorough attribute mapping, testing, clear documentation |
| Replay attacks on IdP-initiated assertions | L | H | Security assessment findings, duplicate assertion usage | Prefer SP-initiated, implement assertion replay detection |
| SAML technical debt impedes modernization | H | M | Difficulty migrating to OIDC, resources consumed by SAML maintenance | Active OIDC migration strategy, sunset planning for SAML |
KPIs / Outcomes
- SAML integration health: Certificate expiration incidents (target: zero)
- SSO success rate: Percentage of SAML authentications successful
- Migration progress: Percentage of applications moved to OIDC
- Mean time to federate new SP: Should be quick with standardized processes
- SAML-related support tickets: Track and trend toward reduction
- Security posture: SAML library currency, vulnerability remediation time