How federation and SSO reduce account sprawl while preserving clear trust, authorization, and lifecycle controls.
Single sign-on and federation are often mentioned together, but they are not identical. Single sign-on is the user experience: sign in once and reach several applications. Federation is the trust relationship: one identity provider authenticates a principal so another service can rely on that result.
The practical value is not merely fewer passwords. The value is central control over identity lifecycle, authentication strength, account status, groups, claims, and sign-in evidence. Without that governance, SSO can become convenient account sprawl with a nicer login screen.
sequenceDiagram
participant U as User
participant SP as Service Provider
participant IdP as Identity Provider
U->>SP: Request application
SP->>IdP: Redirect or request authentication
IdP->>U: Authenticate user
IdP->>SP: Send signed assertion or token
SP->>SP: Map claims to session and permissions
SP->>U: Allow application access
The identity provider proves the user. The service provider still needs to map identity attributes, groups, claims, roles, or scopes into application authorization.
| Requirement | Strong answer |
|---|---|
| Employees need one login for many enterprise apps | SSO through a central identity provider |
| A cloud provider should trust the corporate directory | Federation between the cloud account and the enterprise IdP |
| A SaaS app needs user attributes such as department and group | Federated claims mapped to application roles |
| A contractor should lose all app access when engagement ends | Central lifecycle deprovisioning through the identity source |
| An app needs delegated API access on behalf of a user | OAuth-style delegated authorization, often with OIDC for sign-in |
The strongest design usually avoids local user copies in every target application. Local accounts become stale, difficult to audit, and easy to miss during offboarding.
Federation is a trust relationship, not a blank check. A well-scoped federation design controls:
If a question says “federation is configured” but access is still too broad, the missing work is usually claims mapping, authorization, conditions, or lifecycle review.
After federated sign-in, the target system still decides what the user can do. This is where exam distractors become subtle. A user may authenticate through the correct IdP and still be denied because:
Treat federation as the beginning of the session path, not the end of access design.
| Control | Why it matters |
|---|---|
| Centralized lifecycle | Joiner, mover, and leaver changes flow to connected applications. |
| Group or role governance | Application access follows approved job function instead of ad hoc assignment. |
| Strong authentication policy | Higher-risk apps can require stronger factors or contextual controls. |
| Assertion and token lifetime | Stolen or stale credentials have a shorter usefulness window. |
| Audit correlation | Sign-in events and application actions can be tied to the same identity. |
| Break-glass accounts | Emergency access remains possible when the federation path fails. |
Break-glass accounts are not a reason to keep unmanaged administrator accounts everywhere. They should be rare, monitored, protected, and tested.
| Trap | Better reasoning |
|---|---|
| “SSO means every user can access every app.” | SSO centralizes authentication; app assignment and authorization still matter. |
| “Federation eliminates local policy.” | The relying service still evaluates roles, claims, scopes, and permissions. |
| “Copy users into every application for resilience.” | Prefer central lifecycle with controlled emergency access and documented fallback. |
| “Use the same broad group for all cloud admins.” | Map groups to least-privilege roles and review membership. |
| “Long sessions are more convenient, so they are better.” | Session lifetime should match risk, task duration, and revocation needs. |
A company uses a corporate identity provider for cloud administrator sign-in. A former employee still has access to one SaaS application because that application maintains a separate local account. Which improvement best addresses the root problem?
A. Increase the local account password length
B. Federate the SaaS application with the central identity provider and tie access to lifecycle deprovisioning
C. Disable MFA for the SaaS app to simplify access
D. Create a shared admin account for offboarding
Best answer: B. The issue is identity lifecycle drift caused by local account sprawl. Federation plus centralized deprovisioning reduces the chance that a disabled worker keeps access in a separate system.