Lesson A13.3
Federation lets one trusted identity source provide identity context to another application. Single sign-on can make that experience easier for users, but strong architecture still needs resource-specific authorization, ownership, lifecycle, and evidence.
This lesson stays provider-neutral and conceptual. It uses fictional identity providers, relying services, trust records, and synthetic logs only. No real credentials or live federation systems are used.
Lesson Progress
High School Advanced • A13: Identity, Zero Trust, and Access Control • Lesson 3 of 10
Readiness Check
0/4 ready
Professional Hook
A counselor may authenticate once and then open several approved applications. That can improve usability and reduce duplicate identity stores. But the Student Services Portal, Reporting Dashboard, and Benefits Portal still have different data, responsibilities, and authorization requirements. Federation centralizes some identity trust; it does not erase application boundaries.
Federation answers “Which identity source do we trust?” while the relying service still answers “What may this identity do here?”
Learning Objectives
Explain federation and single sign-on as trust architecture involving identity providers, relying services, identity assertions, ownership, lifecycle, and monitoring.
Distinguish authentication source, federation trust, application authorization, SSO session, external sponsorship, and local fallback access as separate design concerns.
Evaluate fictional federation relationships for excessive trust, stale ownership, broad application scope, weak lifecycle controls, and incomplete evidence.
Analyze how federation can improve identity lifecycle and user experience while still requiring resource-specific authorization and zero-trust review.
Build a Federation Trust Register that becomes the third artifact in the A13 Enterprise Identity and Zero-Trust Review.
Federation Roles
Authenticates the user or workload and provides identity context to another service.
Architecture concern
The relying service should understand exactly what identity source it trusts and under what conditions.
Useful evidence
Provider owner, trust configuration metadata, lifecycle, supported identity populations, monitoring, and change history.
Consumes trusted identity context and still decides what the identity may do inside the application.
Architecture concern
Federated authentication should not be confused with broad application authorization.
Useful evidence
Application owner, accepted identity source, role mapping, resource policy, access review, and authorization logs.
Defines the trust connection between an identity source and a relying service.
Architecture concern
The relationship needs purpose, scope, ownership, lifecycle, and review just like any other security dependency.
Useful evidence
Trust ID, owner, relying service, identity provider, identity population, review date, and status.
Lets an already authenticated user move across approved relying services without repeating the full login experience every time.
Architecture concern
Convenience should not create unlimited trust across all connected applications.
Useful evidence
Session policy metadata, application-specific authorization decisions, session expiration, and monitoring.
Lets an outside organization authenticate its users while the internal organization controls what those users may access.
Architecture concern
Technical trust must remain tied to sponsor, business purpose, population scope, review, and expiration.
Useful evidence
External organization owner, sponsor, identity population, allowed applications, review date, and activity evidence.
Provides exceptional access when a federated path is unavailable or inappropriate.
Architecture concern
Fallback identities can silently bypass normal lifecycle and monitoring if not strongly governed.
Useful evidence
Business reason, owner, emergency purpose, storage method metadata, review cadence, use evidence, and retirement plan.
Federation Principles
Instead of every application verifying identity independently, a relying service accepts identity context from an approved identity source.
Review: Which identity source is being trusted, for which population, and for which relying service?
One sign-in can reduce repeated authentication, but each application still needs its own authorization decisions.
Review: Can a user reach only the applications and functions appropriate to their role?
An identity team can establish who the person is while an application owner decides what that person may do.
Review: Are authentication ownership and application authorization ownership both clear?
Identity context should be limited to what a relying service actually needs to make access decisions.
Review: Is the application receiving only relevant identity metadata?
Federation should be reviewed when applications, providers, business partnerships, ownership, or identity populations change.
Review: What events trigger review or retirement of the federation trust?
An outside organization may authenticate its own users, but the internal organization still owns the decision to accept and authorize them.
Review: Who sponsors the external population and when is the relationship reviewed?
Local accounts can become unmanaged bypass paths if they are permanent, shared, or weakly monitored.
Review: Is fallback access named, bounded, monitored, reviewed, and tested only through safe administrative assurance?
Strong evidence includes federation health, identity sign-ins, application authorization, policy changes, and source health.
Review: Can the organization tell whether the trust relationship is healthy and whether access decisions are behaving as intended?
Trust Dimensions
Core question: Which provider or authority establishes the identity?
Evidence: Identity-provider record, owner, supported population, and current trust metadata.
Core question: Which application accepts the federated identity?
Evidence: Application owner, service inventory, federation configuration record, and access policy.
Core question: Which users or workloads are included?
Evidence: Workforce group, partner population, contractor cohort, or approved service identities.
Core question: Why does the trust relationship exist?
Evidence: Business process, service dependency, partnership requirement, or approved user experience goal.
Core question: Which attributes or claims are actually needed?
Evidence: Role, group, organization, employment state, or other minimal identity metadata.
Core question: What can a successfully federated identity do?
Evidence: Application roles, resource permissions, entitlement mapping, and authorization logs.
Core question: When should the trust relationship change or end?
Evidence: Application retirement, provider change, contract end, owner change, identity-population change, or review date.
Core question: What evidence shows federation and SSO remain healthy and properly used?
Evidence: Sign-in telemetry, authorization events, trust changes, source health, and access reviews.
Vocabulary
A trust arrangement in which one identity system provides identity context that another service accepts for authentication decisions.
The system or authority that authenticates an identity and provides trusted identity context to a relying service.
An application or service that accepts federated identity context and then applies its own authorization rules.
A user experience in which one successful authentication can support access to multiple approved services without repeating the full sign-in flow each time.
A signed or otherwise trusted statement from an identity source that conveys identity context to a relying service.
A piece of identity-related information such as role, organization, or account state used by a relying service.
The controlled translation of identity information from one system into the fields or roles expected by another system.
The documented agreement that one system will accept identity context from another system under defined conditions.
A bounded period in which an authenticated identity interacts with a relying service under current policy.
Federated access involving an identity provider outside the organization, such as a partner or contractor identity source.
A local or alternate identity used when normal federation is unavailable or inappropriate.
The creation, approval, review, modification, suspension, and retirement of a federation relationship.
Fictional Federation Register
Identity provider
Northbridge Workforce Identity Provider
Relying service
Student Services Portal
Identity population
Counselor Workforce Group
Purpose
Workforce SSO for approved student-support workflows
Identity context
Workforce state + counselor role
Authorization
Portal applies counselor-specific application permissions
Owner
Identity Team + Student Services Application Owner
Lifecycle
Quarterly trust review + application/role change trigger
Monitoring
Federation health + sign-in + application authorization logs
Architecture concern
Application authorization remains separate from federated authentication.
Identity provider
Northbridge Workforce Identity Provider
Relying service
Cloud Administration Portal
Identity population
Approved Platform Administrators
Purpose
Base workforce authentication before privileged activation
Identity context
Workforce identity + admin eligibility
Authorization
Privileged access requires separate time-bounded activation
Owner
Identity Team + Platform Engineering
Lifecycle
Monthly privileged trust review
Monitoring
Federation + privileged activation + admin audit
Architecture concern
One emergency privileged session has incomplete post-use review evidence.
Identity provider
Fictional Partner Identity Provider
Relying service
Scheduling Integration Console
Identity population
Approved Partner Support Group
Purpose
Partner support for scheduling integration
Identity context
Partner identity + support group
Authorization
Narrow support functions only
Owner
Integration Owner + Partner Sponsor
Lifecycle
Review due in 30 days
Monitoring
External federation + console authorization logs
Architecture concern
Sponsor is current, but continued partner access must be reviewed.
Identity provider
Northbridge Workforce Identity Provider
Relying service
Reporting Dashboard
Identity population
Reporting Analysts
Purpose
SSO to approved analytics reporting
Identity context
Workforce state + reporting role
Authorization
Dashboard controls dataset/report scope
Owner
Analytics Product Owner
Lifecycle
Quarterly review
Monitoring
Federated sign-in + report access logs
Architecture concern
Reporting role must not imply access to unrelated operational datasets.
Identity provider
Local legacy account
Relying service
Generated Report Storage
Identity population
Legacy Reporting Job
Purpose
Historical automated report delivery
Identity context
Long-lived local account metadata
Authorization
Legacy storage permissions
Owner
Unknown
Lifecycle
No current review date
Monitoring
Partial
Architecture concern
Local fallback path bypasses the governed federation lifecycle and lacks accountable ownership.
Identity provider
Northbridge Workforce Identity Provider
Relying service
HR Benefits Portal
Identity population
Active Workforce
Purpose
Employee self-service SSO
Identity context
Active workforce state
Authorization
Portal limits users to their own benefits workflow
Owner
HR Systems Owner
Lifecycle
Annual trust review + provider/application change trigger
Monitoring
Federation + portal authorization telemetry
Architecture concern
SSO convenience does not expand access beyond each user's own workflow.
Identity provider
Temporary Project Identity Source
Relying service
Migration Console
Identity population
Approved Migration Operators
Purpose
Time-bounded migration support
Identity context
Named temporary operators
Authorization
Migration-specific actions only
Owner
Migration Project Owner
Lifecycle
Expires at migration checkpoint
Monitoring
Federation + migration audit
Architecture concern
The trust relationship must be retired when the project window closes.
Fake Dashboard
Fictional federation ownership, lifecycle, and evidence summary
Federation relationships
7
Workforce, privileged, partner, reporting, legacy, HR, and temporary project relationships
Confirmed
3
Student Services, Reporting Dashboard, and HR Benefits federation are current
Conditional
3
Privileged review, partner renewal, and migration expiration require follow-up
Blocked
1
Legacy local login lacks current ownership and federation lifecycle governance
Fake SOC Alert
Source: Fictional Federation Governance Review • Time: 09:47
SSO and Authorization
The user authenticates to an approved identity source and can move between connected relying services without repeatedly entering credentials.
Each relying service still decides which resources and actions the authenticated identity may use.
Fake Log Panel
[08:10] FED-01 workforce-idp->student-services trust=CURRENT authz=APP_ROLE state=CONFIRMED [08:34] FED-02 workforce-idp->admin-portal privilege=JIT post_review=PARTIAL state=CONDITIONAL [08:58] FED-03 partner-idp->scheduling sponsor=CURRENT review_due=30d state=CONDITIONAL [09:21] FED-04 workforce-idp->reporting role=ANALYST authz=DATASET_SCOPED state=CONFIRMED [09:47] FED-05 local-legacy->report-storage owner=UNKNOWN monitoring=PARTIAL state=BLOCKED [10:12] FED-06 workforce-idp->benefits population=ACTIVE_WORKFORCE state=CONFIRMED [10:38] FED-07 temp-idp->migration expires=PROJECT_CHECKPOINT state=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Federation Anti-Patterns
Why it fails: One successful authentication is treated as authorization across all connected applications.
Better approach: Keep application and resource authorization separate from the SSO experience.
Why it fails: Nobody is accountable for reviewing whether the trust relationship should continue.
Better approach: Assign provider, application, and business owners.
Why it fails: Partner users remain technically valid even after the business relationship changes.
Better approach: Tie external federation to current sponsor, business purpose, population, review, and expiration.
Why it fails: Applications receive identity data they do not need for authorization.
Better approach: Send only the minimum relevant identity context.
Why it fails: A temporary local access path silently becomes a standing bypass around federation governance.
Better approach: Keep fallback access named, bounded, monitored, and reviewed.
Why it fails: Applications continue relying on old assumptions after identity architecture changes.
Better approach: Trigger review on provider, application, ownership, or population changes.
Why it fails: The identity provider is assumed to determine every application permission.
Better approach: Let relying services maintain resource-specific authorization ownership.
Why it fails: The team can see sign-ins but cannot explain what the user did inside each application.
Better approach: Monitor federation health plus relying-service authorization and activity.
Scenario Decision Lab
A partner identity provider is healthy, the integration scope is narrow, and the internal sponsor is current. The federation review date is approaching.
Scenario Decision Lab
A legacy reporting job still uses a local production login outside the main federation model. The current owner is Unknown and monitoring is incomplete.
Safe Fictional Lab
Use fictional identity providers, relying services, identity populations, owners, sessions, and evidence. Do not access or configure any real federation environment.
Create at least ten fictional federation relationships.
Give every relationship a stable FED ID.
Record the identity provider.
Record the relying service.
Record the identity population.
State business or technical purpose.
Record the minimum identity context needed.
Record application authorization ownership.
Record provider owner.
Record relying-service owner.
Record sponsor for external federation.
Record lifecycle review date or change trigger.
Record monitoring evidence.
Classify status as Confirmed, Conditional, Unknown, Blocked, or Retired.
Include at least two workforce SSO relationships.
Include at least one privileged federation relationship.
Include at least two external or partner federation relationships.
Include at least one temporary federation relationship.
Include at least one fallback/local identity and evaluate whether it should remain.
Add change triggers for provider, application, owner, population, partner, privilege, and service-retirement changes.
Lab boundary
Use fictional providers, services, populations, and synthetic evidence only. Do not collect real account information, inspect live federation metadata, test authentication, alter SSO settings, or attempt to access any real identity system.
Analyze the Evidence
Advanced Challenge
A fictional organization currently has three separate local application logins, one partner login, one permanent administrator account, and a legacy reporting account. Redesign the identity experience conceptually using federation and SSO while preserving application-specific authorization.
Primary workforce identity provider
Approved relying services
Identity population per service
Application-specific authorization
Minimal identity context
Privileged federation boundary
Time-bounded privileged activation
External federation sponsor
External federation expiration
Temporary project federation
Fallback/local account governance
Federation lifecycle review
Provider-change trigger
Application-change trigger
Monitoring and source health
Blocked legacy trust that must be retired
The goal is not to centralize every authorization decision. A strong design centralizes identity where appropriate while preserving resource ownership and least-privilege authorization at each relying service.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the third artifact for your A13 Enterprise Identity and Zero-Trust Review: a fictional Federation Trust Register with at least ten trust relationships. Include federation ID, identity provider, relying service, identity population, purpose, minimal identity context, authorization owner, provider owner, relying-service owner, sponsor where needed, lifecycle, monitoring evidence, status, concern, next action, and change trigger.
Confidence / Readiness Reflection
A13.4 moves into Conditional Access and Policy Decisions. Before continuing, make sure you can explain how federation establishes identity context while application authorization still uses its own policy and resource conditions.
I can explain federation as a trust relationship.
I can distinguish identity provider from relying service.
I can explain why SSO does not automatically grant application permissions.
I can evaluate external federation using sponsor, scope, lifecycle, and evidence.
I can explain why fallback local identities still require governance.
Portfolio Build Guide
Make every provider-to-service relationship easy to reference in later A13 lessons.
List the identity provider and relying service instead of describing federation as a generic login feature.
Record identity context separately from the permissions enforced by the relying service.
Make clear which workforce, partner, admin, temporary, or service population is included.
Use review dates and provider/application/owner/population changes as trust triggers.
Federation health, sign-ins, authorization, policy change, and source-health evidence should support major claims.
Do not hide local identities just because they sit outside the federation architecture.
A13.4 will use these federation relationships when evaluating contextual policy decisions.
Key Takeaways
Lesson Safety Boundary
Do not attempt password guessing, account enumeration, authentication bypass, token theft, session hijacking, federation manipulation, privilege escalation, or access to real identity providers. All providers, applications, trust records, and logs in this lesson are fictional and defensive.
Lesson Complete
You now have a federation model built around identity providers, relying services, SSO, application authorization, external trust, lifecycle, fallback access, ownership, and monitoring. Next, A13.4 focuses on Conditional Access and Policy Decisions.