Overview
Single Sign-On enables users to authenticate once and access multiple applications without re-entering credentials. When a user logs into the Identity Provider (IdP), they establish an SSO session that applications (Service Providers, or SPs) trust for subsequent access. SSO dramatically improves user experience by eliminating password fatigue, reduces help desk costs from password resets, and strengthens security by centralizing authentication where MFA and monitoring can be consistently applied. Modern SSO uses federated protocols like SAML 2.0 and OpenID Connect to pass identity assertions between the IdP and applications. Organizations without SSO typically have fragmented authentication, inconsistent security policies, and users maintaining dozens of separate credentials—a recipe for weak passwords and credential reuse.
Architecture & Reference Patterns
Pattern 1: IdP-Initiated SSO Portal
Users start at the IdP portal (e.g., Okta dashboard, Azure AD My Apps) and click application links. The IdP generates an assertion/token and redirects the user to the application. Simple for users but requires training to start at the portal rather than going directly to applications. Best for organizations deploying SSO for the first time.
Pattern 2: SP-Initiated SSO
Users go directly to the application URL. The application redirects unauthenticated users to the IdP, which authenticates them (or recognizes existing SSO session) and redirects back with an assertion. Transparent to users—they just go to the app and end up logged in. Requires each application to be configured with IdP discovery.
Pattern 3: SSO Gateway/Access Manager
An access gateway (reverse proxy) sits in front of applications and handles authentication before requests reach the application. Applications receive identity via HTTP headers without implementing SSO protocols. Essential for legacy applications that can't support modern protocols. Products like ForgeRock Identity Gateway, PingAccess, and Shibboleth SP implement this pattern.
Pattern 4: Desktop SSO (Windows Integrated Authentication)
Users authenticate to their Windows domain at desktop login, and that authentication flows through to web applications via Kerberos/SPNEGO or certificate-based authentication. Provides seamless SSO within the corporate network. Often combined with federation for external access and cloud applications.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| SSO protocol | SAML 2.0, OIDC, WS-Federation | OIDC for new applications; SAML 2.0 for enterprise apps that only support it | Many enterprise apps still only support SAML; support both |
| IdP product | Okta, Azure AD, Ping, ForgeRock, Auth0, custom | Commercial IdP for most organizations; evaluate based on app ecosystem | IdP is critical infrastructure—avoid switching costs by choosing carefully |
| SSO flow pattern | IdP-initiated, SP-initiated, both | SP-initiated for seamless UX; IdP portal for discoverability | SP-initiated is preferred UX; IdP portal is fallback and app catalog |
| Legacy app integration | Access gateway, agent-based, custom integration | Access gateway for header-based apps; avoid agents where possible | Agents are painful to maintain and deploy; gateway centralizes |
| Desktop SSO | Kerberos/SPNEGO, certificate-based, none | Kerberos for Windows-dominated environments; certificates for high security | Desktop SSO dramatically improves on-premises UX |
| IdP redundancy | Single IdP, active-active multi-region, warm standby | Active-active multi-region for critical workloads | IdP outage = all apps down; invest in HA |
Implementation Approach
Phase 0: Discovery
Inputs: Application inventory, current authentication methods, user access patterns, security requirements, compliance requirements Outputs: Application categorization (SSO-ready, needs gateway, custom), authentication flow analysis, user population mapping, prioritized application list for SSO onboarding, IdP selection criteria
Phase 1: Design
Inputs: Discovery outputs, IdP capabilities, security requirements Outputs: SSO architecture document, IdP configuration standards, application integration patterns, session and timeout policies, Single Logout design, MFA integration requirements, monitoring and alerting strategy
Phase 2: Build & Integrate
Inputs: Design documents, IdP platform, pilot applications Outputs: IdP deployed and configured, pilot applications integrated and tested, access gateway deployed (if needed), MFA enabled for SSO, monitoring and alerting operational, user documentation drafted
Phase 3: Rollout
Inputs: Tested SSO infrastructure, prioritized application list, user communication plan, helpdesk readiness Outputs: Applications onboarded in priority waves, users migrated to SSO authentication, legacy authentication methods disabled, helpdesk trained, adoption metrics tracked
Phase 4: Operate
Inputs: Production SSO environment, monitoring dashboards, change management process Outputs: New application onboarding streamlined, SSO availability maintained (target 99.95%+), security monitoring and incident response, IdP upgrades and patches applied, continuous improvement
Deliverables
- SSO architecture document with IdP deployment design
- Application integration guide (SAML, OIDC, header-based)
- IdP configuration standards and naming conventions
- Session and timeout policy document
- Application onboarding checklist and procedures
- Single Logout architecture and testing procedures
- MFA policy integrated with SSO
- Monitoring dashboard for SSO health and adoption
- Incident response playbook for SSO outages
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| IdP outage blocks access to all applications | L | H | IdP monitoring alerts, widespread user complaints | Active-active deployment, health checks, emergency break-glass procedures |
| Certificate expiration breaks SSO | H | H | Approaching expiration dates, federation errors | Automated certificate monitoring, 90/30/7 day alerts, automated renewal |
| Single Logout fails leaving sessions active | M | M | Users remaining logged in after logout, security audit findings | Thorough SLO testing, back-channel logout, session monitoring |
| Legacy app integration delays rollout | M | M | Integration failures, extended timelines | Early assessment of legacy apps, gateway approach, accept exceptions |
| Users bypass SSO with direct credentials | M | M | Direct authentication events, audit findings | Disable direct auth where possible, monitoring for bypasses |
| SSO makes credential theft high-impact | M | H | Account takeover affects multiple apps | Strong MFA on IdP, session monitoring, rapid response procedures |
KPIs / Outcomes
- SSO application coverage: Percentage of applications federated with SSO (target: 100% for SSO-capable apps)
- SSO availability: Target 99.95% uptime for IdP
- User adoption: Percentage of authentications through SSO vs. direct
- Help desk ticket reduction: Password reset tickets should decrease significantly
- Time to onboard new application: Target under 5 business days for standard apps
- Security incidents from credential reuse: Should decrease with SSO adoption