Single Sign On and Federated Identity: One Login to Rule Them All Safely

🎯 CISSP Lens

Pick answers that align business risk, governance intent, and practical control execution.

Single sign on and federated identity both aim to reduce how many times a user must authenticate and how many accounts administrators need to manage.

Single sign on basics

Single sign on means a user authenticates once to a central system, then gains access to multiple applications without logging in again. The central system is typically called an Identity Provider (IdP) and the applications are Service Providers (SPs) or relying parties.

Common SSO characteristics:

• The user authenticates to the IdP
• The IdP issues a token or assertion that proves the user is authenticated
• Applications trust the IdP and accept that token instead of asking for credentials again

Key protocols

Several standards support SSO and federation:

• SAML 2.0: XML based protocol widely used for enterprise SSO to cloud apps. SAML assertions carry authentication and attribute information.
• OAuth 2.0: An authorization framework used to grant limited access to resources. It is not an authentication protocol by itself.
• OpenID Connect (OIDC): A layer on top of OAuth 2.0 that adds identity tokens for authentication.

For CISSP purposes, remember that SAML and OIDC are used for authentication and single sign on, while OAuth focuses on delegated authorization.

Federated identity

Federation extends SSO across organizational boundaries. Instead of creating local accounts for partner users, you:

• Establish a trust relationship with the partner's IdP
• Accept SAML or OIDC assertions from that IdP
• Grant access based on the attributes in those assertions

Each organization maintains its own identity store and authentication processes, but trusts certain assertions from partners.

Kerberos in enterprise SSO

In many on premise environments, Kerberos underpins SSO:

• The user authenticates to the Kerberos Key Distribution Center (KDC)
• The KDC issues a Ticket Granting Ticket (TGT)
• The TGT is used to request service tickets for specific applications
• Applications trust the KDC and accept service tickets instead of prompting for credentials

Kerberos avoids sending passwords across the network and enables seamless SSO within a domain or forest.

SSO security risks

SSO improves usability but introduces specific risks:

• Single point of compromise. If an attacker hijacks an SSO session or compromises the IdP, they may gain access to many applications.
• Session management weaknesses. Long lived tokens or idle sessions increase the window of opportunity for misuse.
• Overly broad assertions. If attributes and group claims are not scoped carefully, users may receive more access than intended.

Mitigations include strong authentication at the IdP, short token lifetimes, secure token storage on clients, and careful session management.

📋 Domain cross-reference

📋 Domain cross-reference

For the exam, focus on these ideas:

• SAML and OIDC are authentication and single sign on protocols. OAuth alone is not.
• In federation, each organization keeps its own user accounts but trusts assertions from a partner IdP.
• Kerberos provides ticket based authentication that avoids sending passwords over the network.
• SSO centralizes authentication, so IdP security and availability are critical.

Scenario questions may ask which protocol to choose, what the security impact of SSO is, or how to fix a misused OAuth based design. Look for misunderstandings where OAuth is incorrectly used as an authentication mechanism.

A growing company adopted a cloud SSO platform and integrated a dozen Software as a Service applications using SAML. Users loved the change. One login gave them access to email, file sharing, customer relationship management, and HR portals.

However, the initial configuration had problems:

• SSO sessions lasted for 24 hours with no idle timeout
• There was no step up authentication for high risk actions, such as payroll changes
• The IdP was deployed with no high availability, so outages blocked access to all integrated apps

An attacker successfully phished a user's primary credentials and stole an active SSO session token. They gained access to multiple applications before the token expired.

After incident response, the security team:

• Shortened token lifetimes and enforced idle timeouts
• Introduced step up MFA for sensitive actions, such as changing bank account details
• Implemented high availability for the IdP, including geographic redundancy
• Tightened device and network policies for SSO access

SSO remained in place, but with controls that matched the concentration of risk.

⚠️ Watch for this mistake: Using OAuth alone for authentication. OAuth is for authorization. Authentication requires an identity layer such as OpenID Connect.

⚠️ Watch for this mistake: Ignoring session management. Long lived SSO sessions without idle timeouts make token theft far more damaging.

⚠️ Watch for this mistake: Trusting federation partners blindly. Accepting assertions without understanding how the partner authenticates users undermines your security.

⚠️ Watch for this mistake: No step up authentication inside SSO sessions. Once a session is established, sensitive actions may still need fresh MFA.

⚠️ Watch for this mistake: Deploying an IdP with no redundancy. If the IdP fails, all dependent applications lose authentication capability.

• ✅ ✅ Inventory all SSO integrations and identify which protocols they use, including SAML, OIDC, and Kerberos.
• ✅ ✅ Review IdP security: authentication strength, MFA coverage, administrative access controls, and logging.
• ✅ ✅ Set clear policies for session duration and idle timeouts that reflect the sensitivity of connected applications.
• ✅ ✅ Implement step up authentication for high risk actions such as changing financial details, modifying privileges, or accessing highly sensitive data.
• ✅ ✅ Document and regularly review federation trust relationships, including how partner IdPs authenticate users and protect their own infrastructure.
• ✅ ✅ Ensure the IdP is highly available, monitored, and included in disaster recovery planning.

• 💡 💡 Single sign on improves usability and reduces password fatigue, but it centralizes authentication risk.
• 💡 💡 SAML and OIDC are used for SSO and authentication, while OAuth focuses on delegated authorization.
• 💡 💡 Federation allows organizations to trust each other's IdPs, reducing the need for duplicate accounts.
• 💡 💡 Kerberos provides ticket based SSO in many enterprise environments and avoids sending passwords over the network.
• 💡 💡 Strong IdP security, good session management, and thoughtful federation design are essential for safe SSO.