5.3 Federated Identity
5.3 Federated Identity
Federated identity allows one organisation or security domain to rely on identity information established by another trusted domain.
Instead of creating a completely separate authentication system for every external service, an organisation can authenticate its users through a trusted Identity Provider and allow third-party services to rely on the resulting identity information.
Authenticate
The Identity Provider establishes the user's authenticated identity.
WHO ARE YOU?Trust
Another service accepts identity information from the trusted provider.
FEDERATIONAuthorise
The receiving service decides what the authenticated identity may do.
LOCAL ACCESS DECISIONFederated Identity with a Third-Party Service
The CISSP objective considers federation across three deployment contexts.
Federation involving systems hosted within traditional organisational infrastructure.
Federation between organisational identities and cloud or SaaS services.
Federation spanning on-premise and cloud identity or application environments.
5.3 Scope
The Big Idea
Federation separates:
who authenticates the identity
from:
who provides the service.
Federation Flow
Authenticate → Assert → Validate → Authorise
👥 Federation Participants Know who performs each function
The person whose identity is being authenticated and represented across the federation.
Authenticates the user and provides trusted identity information to another system.
A term commonly used with SAML for the service that consumes the federated identity assertion.
A system that relies on identity information supplied by another trusted party.
NIST terminology for an entity that manages subscriber accounts, authenticators and related identity services.
OpenID Connect terminology for an authorization server capable of authenticating users and supplying identity information to relying parties.
The underlying architectural question remains:
who establishes identity, and who trusts that result?
Identity Provider vs Relying Party
Authenticates the user.
Produces identity information that another system can validate.
PROVES / ASSERTS
Receives and validates the trusted identity information.
Then determines what the identity may access locally.
TRUSTS / CONSUMES
Federation Roles
🔑 Federation Does Not Transfer the Password The user's primary credential can remain with the Identity Provider
One major benefit of federation is that the relying service does not necessarily need to collect the user's primary authentication credential.
The third-party service can rely on an assertion or token from the trusted identity provider instead.
Assertions, Claims & Tokens
A statement from a trusted identity system containing information about a subject and authentication event.
A piece of information asserted about an identity.
A data structure used to communicate identity or authorization information between systems.
The Identity Provider may communicate that:
- the subject identifier is 381927;
- the user authenticated successfully;
- the user's department is Finance;
- the user's corporate email is alice@example.com.
The receiving service decides which of those attributes matter to its own access policy.
Federation Data
📦 Attribute & Claim Minimisation Share only the identity information the service requires
Federation can transmit identity attributes to external services.
That does not mean every available identity attribute should be shared.
A training application may require:
It may not need:
Federated Claims
SAML 2.0
Security Assertion Markup Language - SAML - is an XML-based standard used to exchange authentication and authorization-related information between security domains.
It is strongly associated with enterprise browser-based federation and Single Sign-On.
SAML
📜 SAML Assertions Trusted XML statements about the subject
SAML assertions can communicate information such as:
Important Validation
Was the assertion issued by the expected trusted Identity Provider?
Can the receiving service verify the integrity and authenticity of the assertion?
Was the assertion intended for this service?
Is the assertion being used within its permitted time conditions?
Is the assertion being delivered to the correct endpoint?
Could an intercepted assertion be improperly reused?
✍️ Signing vs Encrypting Federation Data Integrity/authenticity and confidentiality solve different problems
Helps the recipient verify who issued the assertion or token and whether it has been modified.
AUTHENTICITY + INTEGRITY
Protects the contents from unauthorised reading.
CONFIDENTIALITY
A digitally signed assertion may still be readable unless its contents are separately encrypted or protected by the surrounding transport and architecture.
Confidentiality alone does not prove who generated the identity information.
Signature vs Encryption
OpenID Connect - OIDC
OpenID Connect adds an identity layer on top of OAuth 2.0.
It allows a client - called a Relying Party - to verify the identity of an end user based on authentication performed by an OpenID Provider.
OIDC
🪪 OIDC ID Token Identity is not the same as API authorization
OpenID Connect uses an ID Token to communicate information about the authenticated user and authentication event to the relying party.
Important Claims Can Include
Its purpose is different from an OAuth access token used to access a protected resource.
OIDC Token Distinction
OAuth 2.0
OAuth 2.0 is fundamentally an authorization framework.
It allows a client to obtain limited access to protected resources without requiring the resource owner to give the client their primary credentials.
OpenID Connect = authentication / identity layer built on OAuth.
🎟️ OAuth Roles Understand who owns, requests and serves the resource
Entity capable of granting access to the protected resource.
Application requesting access to the protected resource.
Issues access tokens after appropriate authorization.
Hosts protected resources and accepts appropriate access tokens.
A photo-printing application asks permission to read selected photos from a cloud-storage service.
The user authorizes limited access without giving the photo-printing application their cloud-storage password.
SAML vs OpenID Connect vs OAuth
| Technology | Primary Purpose | Think |
|---|---|---|
| SAML 2.0 | Federated authentication / identity assertions | Enterprise federation and SSO |
| OpenID Connect | Authentication and identity | Who is the user? |
| OAuth 2.0 | Delegated authorization | What resource may this client access? |
Protocol Memory Aid
OIDC = WHO · OAuth = WHAT ACCESS
🪙 JSON Web Token - JWT A token format, not an authentication protocol by itself
JWT is a compact format for representing claims between parties.
It is commonly used in modern identity and authorization systems.
OAuth is an authorization framework.
JWT is a token format that can be used within many different systems.
OpenID Connect is an identity protocol.
Its ID Token is represented as a JWT.
JWT
Establishing Federation Trust
Federation works because the relying system knows which identity provider it trusts and how to validate information received from it.
Define which Identity Provider is trusted.
Allow assertions or tokens to be cryptographically validated.
Configure legitimate authentication, redirect and assertion-consumer locations.
Exchange configuration and trust information between federation participants.
Define which service the assertion or token is intended for.
Agree which identity information is exchanged and how it is interpreted.
Federation Trust
⚙️ Federation Metadata Configuration itself is security-sensitive
Federation participants need trusted information about each other's configuration.
A service is configured to trust a signing certificate belonging to the corporate Identity Provider.
The Identity Provider rotates that certificate.
Federation processes must ensure that trusted configuration is updated safely so authentication does not fail or start trusting an incorrect key.
✅ Validate Before Trusting Never treat an assertion or token as trusted merely because it exists
On-Premise Federation
Federation can occur between systems located within or across traditional organisational data-centre environments.
Considerations
Cloud Federation
Cloud federation commonly allows an organisation to use centrally managed corporate identities with external SaaS and cloud platforms.
Benefits
Risks
Hybrid Federation
Hybrid identity connects traditional on-premise identity infrastructure with cloud identity and application environments.
Security architects should understand where the authoritative identity originates, how identity data is synchronised or federated and what happens when either side becomes unavailable.
🔄 Identity Synchronisation vs Federation Copying identity data and trusting authentication are different things
Identity data is copied or synchronised between systems or directories.
One system relies on identity or authentication information produced by another trusted system.
Sync vs Federation
⏱️ Just-in-Time Provisioning Create the local account representation when first required
Organisations must still ensure that access is removed appropriately when the user leaves or no longer requires the service.
JIT Federation
♻️ Federated Identity Lifecycle Access must disappear when trust or business need ends
An employee leaves the organisation.
Their corporate identity is disabled immediately.
However, a third-party SaaS account created through federation still exists with a separate local password.
The organisation must understand whether local access paths remain after federation ends.
🔓 Federated Access vs Local Accounts Alternative authentication paths can bypass central identity controls
A third-party service may support both:
Corporate federation requires:
MFA + managed device.
The SaaS application also allows an administrator to log in using:
a permanent local password without MFA.
The weaker local path can undermine the stronger federated authentication architecture.
Federation Security
Federation Does Not Eliminate Authorization
The Identity Provider establishes identity.
The relying service still needs to determine:
Two users authenticate through the same corporate Identity Provider.
One is a: standard employee.
The other is: Finance Administrator.
The SaaS application can trust both identities while assigning very different permissions.
Federation
🗺️ Attribute & Role Mapping Identity data must be interpreted consistently
Federated services often use identity attributes to determine local roles or permissions.
The IdP sends:
role = employee
The SaaS application incorrectly maps the value to:
administrator.
Authentication can work perfectly while authorization is dangerously wrong.
Federation Creates More Than One Session
Federated access may involve separate sessions at the Identity Provider and relying service.
A user logs out of the Identity Provider.
The third-party application's own session may still remain active depending on the architecture and logout implementation.
🟢 Identity Provider Availability Central identity can become a central dependency
Federation centralises authentication.
This can improve security and consistency, but it also makes the Identity Provider highly important to availability.
One corporate Identity Provider authenticates access to:
The Identity Provider fails.
Multiple unrelated applications may become inaccessible simultaneously.
Federation Trade-Off
The Identity Provider Is Compromised
Assume an attacker gains control of a trusted Identity Provider.
A system that can assert identities to many applications is a particularly high-value security asset.
🔑 Signing-Key Compromise Trust frequently depends on cryptographic verification
Federation participants often use cryptographic signatures to establish trust in assertions and tokens.
An attacker obtains a federation signing key.
Depending on the architecture, they may be able to produce cryptographically valid identity information that appears to originate from the trusted issuer.
Security Requirements
🎟️ Token Theft & Replay Attackers may target the result of authentication rather than the password
Once authentication succeeds, tokens and sessions can become valuable attack targets.
Important Defences
↪️ Redirect & Endpoint Security Federation depends on messages arriving at the correct places
Modern federation flows frequently redirect users between services and identity systems.
Incorrect or overly permissive redirect configuration can allow authentication information to be sent somewhere it was never intended to go.
A client accepts arbitrary redirect destinations supplied by the requester.
An attacker attempts to manipulate the flow so authentication information is returned to an attacker-controlled location.
Federation Is a Security Relationship
Establishing federation with another organisation or service creates an ongoing trust relationship.
Is the partner's identity process strong enough for the intended service?
Which authentication methods protect the identities?
How are federation signing and encryption keys protected and rotated?
Which identity information is exchanged and how is it protected?
What happens if the partner identity service becomes unavailable?
How will participants respond if the trust relationship is compromised?
How are identities and access removed when they are no longer required?
Can anomalous federation events be detected?
Ask: "Should these systems trust each other, and under what conditions?"
Corporate Employees Access a SaaS Platform
Partner Organisation Access
Organisation A allows employees from Organisation B to access a shared business application.
Organisation A creates and maintains separate accounts and passwords for Organisation B's employees.
Organisation B authenticates its own employees.
Organisation A's application trusts approved identity assertions from Organisation B.
Organisation A now partly depends on Organisation B correctly managing its workforce identities and promptly reflecting changes in the federation relationship.
On-Prem Identity + Cloud Applications
Hybrid environments can contain several copies or representations of an identity. Architects need to understand which system is authoritative and how changes propagate.
🔀 Federation Broker Intermediate between multiple identity and service domains
A federation broker can intermediate trust between multiple identity providers and relying services.
🎓 CISSP Scenarios Recognise the federation principle
A cloud application relies on the customer's corporate authentication service to identify employees.
Which concept?
Federated identity.
A corporate identity system authenticates an employee and issues identity information to another service.
Which role?
Identity Provider.
A SaaS application accepts trusted identity information from the organisation's IdP.
Which role?
Relying Party / Service Provider.
An enterprise browser application receives an XML-based identity assertion from an IdP.
Which technology is likely involved?
SAML.
A modern web application receives an ID Token after authentication by an OpenID Provider.
Which protocol?
OpenID Connect.
A third-party application is granted limited access to an API without receiving the user's password.
Which framework?
OAuth 2.0.
Management describes OAuth 2.0 as primarily an authentication protocol.
Is that precise?
No. OAuth is fundamentally an authorization framework.
Authentication functionality is required on top of OAuth 2.0.
Which standard is specifically designed for this?
OpenID Connect.
An OIDC client receives information representing the authenticated user's identity.
Which token is particularly relevant?
ID Token.
An OAuth client presents a token to access a protected API.
Which token?
Access token.
A developer uses the terms ID Token and access token interchangeably.
What is wrong?
They serve different purposes: identity versus protected-resource access.
A signed SAML assertion has been modified after issuance.
Which control should detect this?
Digital signature validation.
A token is cryptographically valid but was issued by an identity provider the application does not trust.
Should it be accepted?
No. The issuer must also be trusted.
A valid token was issued for Application A and is presented to Application B.
Which validation is particularly relevant?
Audience validation.
An old assertion is captured and reused after it should no longer be accepted.
Which threat?
Replay.
A SAML assertion has a valid signature but contains sensitive attributes in readable form.
What distinction matters?
Signing provides integrity/authenticity; encryption provides confidentiality.
A third-party application receives every employee attribute even though it requires only name and corporate email.
Which principle should be applied?
Attribute / data minimisation.
A service trusts an assertion saying the user is in the Finance department and maps that attribute to Finance permissions.
Which process?
Attribute / role mapping.
The IdP authenticates the correct user, but the SaaS application mistakenly maps every employee to administrator.
Which component failed?
Local authorization / attribute mapping.
A user accesses a federated application for the first time and a local account representation is created automatically.
Which concept?
Just-in-Time provisioning.
A user account is automatically created through federation but never deleted when the employee leaves.
What is the concern?
JIT provisioning without effective deprovisioning.
The organisation disables a former employee's corporate account, but the SaaS service still permits a separate local password.
Primary concern?
Alternative local authentication bypasses the federated lifecycle.
Identity data is copied from an on-prem directory to a cloud directory.
Is this necessarily federation?
No. This may simply be identity synchronisation.
A cloud service relies on authentication performed by another identity domain.
Which concept?
Federation.
On-prem identity infrastructure is integrated with cloud identity and SaaS applications.
Which deployment model?
Hybrid identity.
The central corporate IdP fails and users cannot access numerous unrelated SaaS applications.
Which concern?
Centralised identity-provider availability dependency.
An attacker compromises the private signing key used by a trusted federation issuer.
Why is this serious?
The attacker may potentially create information that appears to originate from the trusted issuer.
A user completes strong MFA legitimately but an attacker then steals the resulting authentication session.
Which lesson?
Strong authentication does not eliminate token and session theft.
A third-party service allows arbitrary authentication-response redirect destinations.
Primary concern?
Authentication information may be redirected to an unintended recipient.
An organisation federates authentication with a business partner.
The partner then suffers a major identity-system compromise.
Which principle?
Federation creates a transitive third-party trust risk.
A user logs out of the corporate IdP but remains authenticated to a third-party application.
Which area should be examined?
Federated session and logout management.
Multiple Identity Providers connect to multiple applications through a central intermediary.
Which architecture?
Federation broker.
Recognise the Clue Words
Authenticates User
Source of identity.
Identity ProviderTrusts Identity
Consumes assertion.
Relying Party / SPXML Identity Assertion
Enterprise federation.
SAMLID Token
Authentication / identity.
OpenID ConnectDelegated API Access
Limited authorization.
OAuth 2.0Who Is the User?
Identity layer.
OIDCWhat May Client Access?
Delegated access.
OAuthClaims Container
Token format.
JWTWho Issued Token?
Trust source.
IssuerWho Is Token For?
Intended recipient.
AudienceWho Sent / Changed?
Integrity and authenticity.
Digital SignatureWho Can Read?
Confidentiality.
EncryptionCreate Account on First Login
On-demand user creation.
JIT ProvisioningCopy Directory Information
Not automatically trust federation.
SynchronisationTrust Authentication Elsewhere
Cross-domain identity.
FederationOn-Prem + Cloud
Mixed architecture.
HybridSame Identity Across SaaS
Central trusted authentication.
Cloud FederationIdP Down → Apps Unavailable
Central dependency.
Availability RiskIdP Compromised
Trusted assertions affected.
Federation Trust RiskCorrect User, Wrong Role
Identity succeeded.
Authorization Mapping Failure⚠️ Common CISSP Mistakes Federation questions often test what each protocol actually does
The relying service can trust identity information without receiving the user's primary password.
The IdP establishes authentication.
The service provider consumes the identity information.
The IdP can correctly authenticate a user while the relying party still grants inappropriate permissions.
SAML is strongly associated with identity federation.
OAuth provides delegated authorization.
OAuth 2.0 is fundamentally an authorization framework.
OpenID Connect adds an identity/authentication layer on top of OAuth 2.0.
ID Tokens communicate authenticated identity.
Access tokens are used to access protected resources.
JWT is a format for representing claims.
Signing addresses authenticity and integrity.
Encryption addresses confidentiality.
Issuer, audience, validity and other conditions still require validation.
Synchronisation copies identity information.
Federation establishes trust in identity information from another system.
Creating users automatically does not guarantee they will be removed correctly.
Local credentials may provide an alternative authentication path that requires separate protection.
Relying services may maintain their own sessions.
Centralisation improves consistency but increases the importance of the central Identity Provider.
Federation should transmit only appropriate attributes and support only the access required by the business relationship.
Quick Reference
| If you see... | Think... |
|---|---|
| Authenticates user for another service | Identity Provider |
| Consumes trusted identity | Relying Party / Service Provider |
| Trusted statement about identity | Assertion |
| Individual piece of identity information | Claim / Attribute |
| XML enterprise identity federation | SAML 2.0 |
| Authentication layer on OAuth 2.0 | OpenID Connect |
| Delegated authorization | OAuth 2.0 |
| Identity token in OIDC | ID Token |
| Token for protected resource | Access Token |
| Claims token format | JWT |
| Verify source and integrity | Digital Signature |
| Protect token contents | Encryption |
| Which trusted party issued it? | Issuer |
| Which service should accept it? | Audience |
| Old assertion reused | Replay |
| Create account at first federated login | JIT Provisioning |
| Copy identity between directories | Synchronisation |
| Trust authentication from another domain | Federation |
| On-prem + cloud identity | Hybrid |
| IdP unavailable | Federation Availability Risk |
| Compromised trusted signing key | Federation Trust Compromise |
| Correct identity mapped to wrong permissions | Authorization / Attribute Mapping |
| Local password bypasses corporate IdP | Alternative Authentication Path |
Protocol Memory Aid
SAML = Federation · OIDC = WHO · OAuth = ACCESS · JWT = FORMAT
Federation Memory Aid
5.3 Master Memory Aid
The Federation Architect's Questions
Key Takeaways
Federated identity allows one security domain to rely on identity information established by another trusted domain.
CISSP 5.3 focuses specifically on federated identity with third-party services across on-premise, cloud and hybrid environments.
The Identity Provider authenticates the subject and provides trusted identity information.
The Service Provider or Relying Party consumes and validates that information.
Federation separates who authenticates the user from who provides the application or service.
Federation does not require the user's primary password to be shared with every relying service.
Assertions and identity tokens carry information about authenticated identities between federation participants.
Claims are individual statements about the identity, such as subject, email, department or other attributes.
Only identity attributes genuinely required by the relying service should be shared.
SAML is an XML-based federation standard commonly associated with enterprise identity federation and SSO.
SAML commonly involves an Identity Provider issuing an assertion that is validated by a Service Provider.
Assertion validation can include issuer, signature, audience, timing, destination and replay-related checks.
Digital signing and encryption perform different functions.
Signing supports authenticity and integrity. Encryption provides confidentiality.
OpenID Connect provides an identity and authentication layer built on top of OAuth 2.0.
In OpenID Connect, the OpenID Provider authenticates the user and the Relying Party consumes identity information.
The OIDC ID Token communicates information about the authenticated identity.
OAuth 2.0 is fundamentally a delegated authorization framework.
A useful CISSP distinction is: OIDC answers "who is the user?" while OAuth addresses delegated access to protected resources.
An OIDC ID Token and an OAuth access token serve different purposes and should not be treated as interchangeable.
JWT is a token format for representing claims and is not by itself an authentication protocol.
Federation trust can depend on issuer configuration, cryptographic keys, metadata, endpoints and agreed claims.
A token or assertion should be validated before it is trusted.
Important validation includes confirming the expected issuer, signature, intended audience and validity conditions.
On-premise federation allows identity trust between services associated with traditional organisational infrastructure.
Cloud federation allows organisations to use centrally managed corporate identity with SaaS and cloud providers.
Hybrid federation connects traditional on-premise and cloud identity environments.
Identity synchronisation and federation are not the same thing. Synchronisation copies identity information; federation establishes trust in identity information produced elsewhere.
Just-in-Time provisioning can create a local user representation when a federated identity first accesses a service.
JIT provisioning does not automatically solve deprovisioning.
Alternative local authentication methods can undermine centrally controlled federation if they provide a weaker route into the service.
Federation does not remove the relying party's responsibility for authorization.
Correct authentication combined with incorrect role mapping can still produce excessive access.
Federation can involve multiple sessions. Logging out from the Identity Provider does not necessarily guarantee that every relying-party session has also ended.
Centralised Identity Providers improve consistency but create important security and availability dependencies.
Compromise of a highly trusted Identity Provider can affect many relying services.
Federation signing keys are high-value security assets because relying systems use them to validate trusted identity information.
Attackers may target assertions, tokens and authenticated sessions rather than attempting to defeat the original authentication mechanism.
Third-party federation should be treated as an ongoing security relationship with appropriate governance, monitoring, lifecycle management and incident-response arrangements.
The central CISSP concept is: the IdP authenticates, trusted identity information crosses the trust boundary, the relying party validates it and then performs its own authorization decision.
📚 Sources & Further Reading Federation, SAML, OpenID Connect and OAuth references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-63C-4 - Digital Identity Guidelines: Federation and Assertions
View current NIST federation guidance - NIST SP 800-63-4 - Digital Identity Guidelines
View NIST Digital Identity Guidelines - OASIS - SAML 2.0 Technical Overview
View the SAML technical overview - OASIS - SAML 2.0 Core Specification
View the SAML 2.0 core standard - OpenID Foundation - OpenID Connect Core 1.0
View the OpenID Connect specification - IETF RFC 6749 - The OAuth 2.0 Authorization Framework
View the OAuth 2.0 specification - IETF RFC 9700 - Best Current Practice for OAuth 2.0 Security
View current OAuth 2.0 security best practice - IETF RFC 7519 - JSON Web Token
View the JWT specification