Federation and single sign-on — SY0-701
Master federation and SSO for CompTIA Security+ SY0-701: how identity providers, relying parties, and assertions work together across networked systems.
WHAT IT IS
Federation is "a process that allows for the conveyance of identity and authentication information across a set of networked systems." (NIST SP 800-63-4)
Single sign-on (SSO) is "an authentication process by which one account and its authenticators are used to access multiple applications in a seamless manner, generally implemented with a federation protocol." (NIST SP 800-63-4)
The relationship between the two: federation is the broader architecture; SSO is a specific capability that federation enables. A subscriber authenticates once to an identity provider (IdP) and subsequently obtains services from multiple relying parties (RPs) without re-entering credentials. (NIST SP 800-63C)
Mental model
Think of federation as a trusted embassy system. Your home country (the IdP) issues your passport. Foreign countries (RPs) accept that passport at their borders rather than issuing their own. The passport itself is the assertion — a signed statement that conveys who you are and how you authenticated.
Three actors, one transaction:
| Actor | Role | NIST term |
|---|---|---|
| The authenticating service | Issues the assertion after verifying the subscriber | Identity Provider (IdP) |
| The consuming service | Accepts the assertion to grant access | Relying Party (RP) |
| The end user | Holds credentials at the IdP only | Subscriber |
The RP never sees the subscriber's credential — it sees only the assertion the IdP signed.
When to use it
The exam distinguishes federation/SSO from adjacent concepts. The key decision is where authentication lives:
| Scenario | Right model | Why |
|---|---|---|
| A single application verifies its own users directly | Local/direct authentication | No cross-domain trust needed |
| A user must access multiple applications with one login, all within the same organization | SSO via federation | One IdP, multiple in-org RPs |
| Two separate organizations need to share identity (e.g., a contractor accessing a partner's app) | Federated trust across domains | Cross-domain identity conveyance |
| A user's identity must be verified at assurance levels matching sensitivity of the resource | Federation Assurance Level (FAL) controls | FAL governs assertion security, not authentication strength |
Federation does not eliminate the need for strong authentication — it distributes trust so strong authentication happens once, at the IdP.
COMMON MISCONCEPTION
SSO is not the same as federation, and federation is not the same as SSO.
SSO is a user-experience outcome (authenticate once, access many). Federation is the technical and organizational architecture that makes cross-domain SSO possible. You can have SSO inside a single organization without any federation. You can have federation without SSO — two organizations may federate identity for attribute sharing without providing seamless login.
A related trap: candidates sometimes conflate the IdP with a Certificate Authority (CA). The NIST glossary is precise on this point: in federated transactions, the IdP "creates an assertion for the subscriber and transmits the assertion to the RP" (NIST SP 800-63-4). A CA issues certificates and validates public keys; it is not the same role as an IdP issuing session assertions, even though both participate in trust chains.
A third trap: assuming that because a user has SSO access, their session at every RP is equally strong. The Federation Assurance Level (FAL) is defined by NIST as "a category that describes the process used in a federation transaction to communicate authentication events and subscriber attributes to an RP." (NIST SP 800-63-4) A high-assurance IdP authentication can still result in a lower-FAL assertion if the assertion is not properly protected in transit.
How it shows up on the exam
Questions in this area target the ability to distinguish roles and trust direction rather than recall protocol syntax. Candidates often confuse:
- Which party issues the assertion (IdP) versus which party consumes it (RP) — the trust flows from the RP toward the IdP, not the other way around.
- The scope of SSO: whether a scenario describes a truly federated cross-domain arrangement or a simpler same-domain authentication service.
- The meaning of a bearer assertion versus a holder-of-key assertion: NIST SP 800-63C distinguishes bearer assertions, which "can be presented by any party as proof of the bearer's identity," from holder-of-key assertions, which require the subscriber to "prove possession of the key referenced in the assertion directly to the RP." A question about assertion replay risk is probing this distinction.
Signal phrases to notice in stem text: "cross-domain authentication," "partner organization access," "authenticate once," "identity provider," "relying party," "SAML assertion," "OpenID Connect token." These anchor the scenario in federated identity, not local authentication or PKI.
The cognitive target is application — given a described trust relationship or a described failure mode (expired assertion, intercepted token, misconfigured RP), identify the correct component or the correct control.
Sequence: federated SSO transaction
The subscriber's credential is only ever presented to the IdP. The RP trusts the IdP's signed assertion rather than the raw credential.
Related concepts
- Identity lifecycle — federation depends on identities being correctly provisioned and deprovisioned; a federated account that is not terminated at the IdP persists across all connected RPs.
- Access control models — the RP uses information in the assertion to make authorization decisions; understanding how attributes map to permissions is the next layer after authentication.
- Multifactor authentication — MFA strengthens the authentication event at the IdP; that assurance is then communicated to RPs through the assertion, which is why IdP-level MFA can satisfy the MFA requirement for downstream RPs.
Sources
Every claim on this page traces to the public exam blueprint and official documentation: