Cyber Security Quiz: Sso And Federation
10 questions · exam conditions
0:00
Sso And FederationQuestion 1 of 10

A company configures six internal applications to use the same username and password. Each application still validates a locally stored password hash, but a synchronization service keeps all six passwords identical.

Which statement best characterizes this design?

It is federated SSO because a synchronization service distributes one credential among multiple applications.
It is SSO because users enter the same credential, even though each application authenticates them separately.
It is password synchronization rather than true SSO because each application still performs its own authentication.
It is federation rather than SSO because the applications maintain separate accounts within one organization.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Sso And Federation

Practice Sso And Federation in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Sso And Federation, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A company configures six internal applications to use the same username and password. Each application still validates a locally stored password hash, but a synchronization service keeps all six passwords identical.

Which statement best characterizes this design?

  1. It is federated SSO because a synchronization service distributes one credential among multiple applications.
  2. It is SSO because users enter the same credential, even though each application authenticates them separately.
  3. It is password synchronization rather than true SSO because each application still performs its own authentication. (correct answer)
  4. It is federation rather than SSO because the applications maintain separate accounts within one organization.
Explanation: When a question asks you to classify an authentication architecture, focus on where and how authentication actually happens — not just what the user experiences on the surface. True Single Sign-On (SSO) means a user authenticates once to a central authority, and that authenticated session is passed to other applications. The applications trust the central assertion rather than re-validating the credential themselves. In the scenario described, each of the six applications still independently validates a locally stored password hash. The synchronization service only ensures those hashes stay identical — it does not authenticate on anyone's behalf. This makes it password synchronization, which is answer C, the correct choice. Answer A is wrong because federation involves a trust relationship between separate identity domains, typically across organizations, using a standards-based protocol (like SAML or OAuth). A sync service distributing matching passwords is not federation — it's replication. Answer B is the most tempting distractor. Yes, the user enters the same credential, but "same experience" is not the definition of SSO. The defining feature of SSO is a single authentication event, not a single password. If each app is independently verifying credentials, you have multiple authentication events — regardless of whether the password happens to be identical. Answer D misapplies "federation." Federation is about trust between distinct identity domains (often across organizations), not simply maintaining separate accounts internally. Nothing in this scenario involves cross-domain trust. Study tip: On authentication questions, always ask yourself: who performs authentication, and how many times? Same password ≠ SSO. One authentication event, trusted everywhere = SSO.

Question 2

An organization enables federated SSO for a software-as-a-service application. A terminated employee is disabled in the corporate identity provider, but the employee's application account and stored files remain present in the service.

Which conclusion best explains the situation?

  1. SSO can block new federated sign-ins without automatically deleting or disabling the application's locally provisioned account and data. (correct answer)
  2. Federation has failed because disabling an identity provider account must immediately erase every linked service account.
  3. The service must still accept the employee's corporate password until its local account and files are manually removed.
  4. The remaining account proves that the service was using password synchronization instead of federated authentication.
Explanation: When studying federated SSO (Single Sign-On), keep two separate concepts distinct in your mind: authentication (verifying identity at login) and provisioning (creating, maintaining, or removing accounts and their associated data). Federation handles the first; it doesn't automatically manage the second. In a federated SSO setup, the identity provider (IdP) acts as the gatekeeper for new login attempts. When the corporate IdP disables the terminated employee, it immediately blocks any future federated sign-ins — the employee cannot authenticate through the IdP again. However, the SaaS application may have already created a local account record and stored files during previous sessions. Disabling the IdP account does nothing to clean up what already exists on the service side. That cleanup requires a separate process, often called deprovisioning, which may be manual or automated through a protocol like SCIM. Answer A correctly captures this boundary: federation blocks new sign-ins, but orphaned accounts and data persist until explicitly removed. Answer B is wrong because federation hasn't "failed" — it's working exactly as designed. Immediate erasure of linked accounts is not part of the federated authentication standard, and expecting it reflects a misunderstanding of what federation promises. Answer C is wrong because the employee cannot use their corporate password to sign in once the IdP account is disabled. The remaining account is a data artifact, not an open authentication pathway. Answer D is wrong because password synchronization is a completely different architecture. The presence of a local account is consistent with standard federation, not evidence of password sync. Study tip: On security exams, whenever you see deprovisioning scenarios, ask yourself: "Is this an authentication problem or an account lifecycle problem?" They require different solutions.

Question 3

A cloud identity provider becomes unavailable for thirty minutes. Before the outage, some users had already signed in to a federated customer-management application; other users had not yet started work.

Which outcome is most consistent with a typical SSO deployment?

  1. All active application sessions must terminate immediately because they continuously depend on the identity provider.
  2. All users can sign in normally because each application always stores a backup copy of the central password.
  3. Only administrators are affected because federation availability requirements do not apply to ordinary users.
  4. Existing application sessions may continue, while new sign-ins or required reauthentication may fail during the outage. (correct answer)
Explanation: When you see a question involving SSO (Single Sign-On) and federation, focus on when authentication actually occurs versus when an existing session is simply being used. These are two distinct events, and understanding the difference is the heart of this question. In a typical federated SSO deployment, the identity provider (IdP) is only contacted at the moment of authentication — when a user logs in and the application requests a token (often a SAML assertion or JWT). Once that token is issued and the application establishes a session, the application manages that session independently. It doesn't ping the IdP on every page load. This means users who were already authenticated before the outage can continue working normally for the duration of their session. Users who need to authenticate during the outage, however, will fail — because that initial handshake with the IdP is unavailable. That's exactly what D describes, making it the correct answer. A is wrong because it treats session maintenance as continuously IdP-dependent. Sessions are managed locally by the application after initial authentication; they don't require a live IdP connection to persist. B is wrong because federated SSO deliberately removes per-application password storage — the whole point is to centralize identity. Applications don't keep "backup passwords." C is wrong because federation availability affects all users equally at sign-in time; there is no special exemption for ordinary users. For your exam, remember this pattern: IdP is needed to create a session, not to maintain one. Any question about IdP outages should prompt you to ask, "Is this about starting authentication or continuing an existing session?"

Question 4

Company X has one internal authentication service that lets employees access several applications after one sign-in. Company X then allows employees of Company Y to access one of those applications by trusting identity information issued by Company Y.

Which statement best distinguishes the two capabilities in this scenario?

  1. The internal arrangement is password synchronization, while the Company Y arrangement is privileged access management.
  2. The internal arrangement provides SSO, while the Company Y arrangement adds federation across separate identity domains. (correct answer)
  3. The internal arrangement provides federation, while the Company Y arrangement adds local authentication to the application.
  4. Both arrangements are federation only, because SSO cannot be implemented within a single organization's identity domain.
Explanation: When you see a question contrasting how users authenticate within an organization versus across organizations, you're being tested on the distinction between Single Sign-On (SSO) and federation — two related but distinct identity concepts. SSO means a user authenticates once to a central identity provider and gains access to multiple applications within the same trust domain — no repeated logins. Federation extends that idea across organizational boundaries: a separate organization's identity assertions are trusted, allowing their users to authenticate with their own credentials and still gain access to your resources. The two concepts often work together but solve different problems. Option B is correct because the scenario describes exactly this layered architecture. Company X's internal service — one login, multiple apps — is classic SSO. When Company Y's employees are granted access by trusting Company Y's identity provider, that's federation: two separate identity domains establishing a cross-domain trust relationship. Option A is wrong on both counts. Password synchronization is a credential-management technique (copying passwords across systems), not what's described internally. Privileged Access Management (PAM) governs elevated administrative access, which has nothing to do with Company Y's arrangement. Option C reverses the definitions entirely. The internal arrangement is SSO, not federation, and the Company Y arrangement doesn't add "local authentication" — it adds federated cross-domain trust. Option D is false. SSO absolutely can and routinely does exist within a single organization's identity domain. Federation is an extension of that concept, not a replacement. A useful memory anchor: SSO = one key for your building; federation = your key also works in a partner's building.

Question 5

A university federates its identity system with a research portal. Any university user can successfully authenticate to the portal, but only principal investigators should be able to create research projects.

What additional control is most directly required to enforce the stated restriction?

  1. The portal should require principal investigators to use a second password after federated authentication.
  2. The university should create a separate federation protocol exclusively for principal investigators.
  3. The portal should treat every valid university assertion as proof that the user is a principal investigator.
  4. The portal should authorize project creation using a trusted role or entitlement associated with the authenticated identity. (correct answer)
Explanation: When you see a question mixing federated identity with access restrictions, train yourself to separate two distinct concepts: authentication (proving who you are) and authorization (determining what you're allowed to do). Federation handles authentication — it tells the portal "this person is a valid university user." But authentication alone never guarantees appropriate access to specific resources or actions. The correct answer is D because project creation is a privileged action that requires authorization beyond mere identity confirmation. The portal should consume a trusted attribute — such as a role claim or entitlement (e.g., role=principal_investigator) — embedded in or derived from the federated assertion, and use that attribute to gate the project-creation function. This is standard Role-Based Access Control (RBAC) layered on top of federated authentication, and it's the most direct, scalable solution. Answer A is a trap that confuses authorization with a second authentication factor. Adding another password doesn't establish what the user is permitted to do — it only re-verifies identity. Answer B overcomplicates the architecture unnecessarily. Creating an entirely separate federation protocol for a subgroup of users is a heavy, impractical solution when role attributes already exist within standard federation frameworks like SAML or OIDC. Answer C represents a critical logical flaw — treating every authenticated university user as a principal investigator completely defeats the stated restriction and would grant project-creation rights to everyone, not just PIs. As a study tip: on security exams, whenever a question describes a group that can authenticate but shouldn't have full access, the answer almost always involves authorization controls (roles, entitlements, policies) — not additional authentication steps.

Question 6

A company plans to place ten business applications behind one SSO identity provider. A security analyst notes that this will reduce repeated password entry but may increase the impact of one type of compromise.

Which risk most directly supports the analyst's concern?

  1. Every federated application will automatically receive administrative privileges from the central identity provider.
  2. A stolen central SSO session or compromised identity-provider account may provide access to several connected applications. (correct answer)
  3. Each application will need to retain a separate copy of the user's central password for offline validation.
  4. Authorization rules in all connected applications will be replaced by one universal identity-provider rule.
Explanation: When a question mentions SSO (Single Sign-On) and asks about increased impact from a compromise, you should immediately think about the security trade-off at the heart of federated identity: convenience often concentrates risk. SSO reduces authentication friction, but it also creates a single point of failure — if that central credential is stolen, the blast radius expands dramatically. This is exactly the concern in answer B. If an attacker steals a valid SSO session token or compromises the identity provider's account directly, they can move laterally into every application trusting that provider — potentially all ten at once. The analyst isn't saying SSO is bad; they're saying one successful credential theft now unlocks many doors instead of one. That's the direct, realistic risk SSO introduces. A is wrong because SSO handles authentication (who you are), not authorization (what you can do). Connected applications still manage their own privilege levels independently; SSO doesn't automatically grant admin rights to anything. C is wrong because it describes the opposite of how SSO works. The entire point of SSO is that applications delegate authentication to the identity provider — they do not store local copies of passwords for offline checks. D is wrong for the same reason as A: authorization rules remain application-specific. The identity provider verifies identity, but each app enforces its own access policies. SSO doesn't collapse all authorization into one universal rule. For the exam, remember this pattern: SSO trades distributed risk for concentrated risk. Any question pairing SSO with "increased impact" is pointing you toward credential consolidation and lateral access as the core threat.

Question 7

An employee opens a cloud expense application and is redirected to the employer's sign-in page. After authentication, the browser returns to the expense application carrying identity information that the application validates. The employee never gives an expense-application password to the employer's sign-in page.

Which interpretation of this interaction is most accurate?

  1. The expense application is the identity provider because it decides which expense functions the employee may use.
  2. The employer is the identity provider, and the expense application relies on its assertion while retaining local authorization decisions. (correct answer)
  3. The employer is synchronizing the employee's password to the expense application before each authenticated session begins.
  4. The expense application authenticates the employee locally, while the employer acts only as an authorization server.
Explanation: When you see a scenario involving two separate systems where one handles login and the other handles functionality — without passwords ever crossing between them — you're looking at federated identity and the SAML/OAuth/OIDC family of protocols. The key roles to distinguish are the Identity Provider (IdP), which authenticates the user and issues assertions, and the Service Provider (SP) or relying party, which accepts those assertions and makes its own authorization decisions. In this scenario, the employer's sign-in page performs the authentication, then passes an identity assertion (a token or assertion document) back to the expense application via the browser. The expense application trusts that assertion without ever seeing the employee's password. This perfectly describes B: the employer is the IdP, and the expense application is the SP that relies on the employer's identity claim while independently deciding what the employee can do within the app (authorization remains local). A confuses authorization with identity provision. The expense application does control which features are accessible, but controlling what you can do is authorization — not authentication or identity provision. The IdP is whoever vouches for who you are. C describes credential synchronization or password replication, which is a completely different architecture. No password is being copied here — the whole point of federation is that credentials never leave the IdP. D inverts the roles entirely. The employer isn't an authorization server in this flow; it's the authenticating party. The expense application handles authorization locally. A reliable rule: whoever the user logs in to = the IdP; whoever trusts that login = the SP. Burn that distinction into memory before exam day.

Question 8

A service provider is onboarding users from a new federation partner. The provider proposes linking an incoming federated user to any existing local account that has the same unverified display name. Several users at the partner have identical names.

Which approach would most directly reduce the risk of assigning a federated user to the wrong local account?

  1. Accept the display-name match only when the user also knows the local account's current password, treating password confirmation as sufficient proof of ownership.
  2. Create one shared local account for every set of duplicate display names and rely on session logs to distinguish individual users after the fact.
  3. Map accounts using a trusted, stable unique identifier from the partner's assertions and apply an explicit account-linking process where ambiguity remains. (correct answer)
  4. Treat the federation partner's successful authentication as proof of ownership of every local account whose display name matches the asserted identity.
Explanation: When a service provider links federated identities to local accounts, the central risk is account takeover through identifier collision — matching the wrong person to an existing account because the matching criteria are weak or non-unique. Display names are notoriously unreliable: they're user-controlled, often duplicated, and unverified. Any matching scheme built on display names alone is fragile by design. Option C is correct because it addresses both problems simultaneously. A trusted, stable unique identifier — such as a NameID or subject identifier issued by the authoritative federation partner — is opaque to collisions and tied to a single identity at the source. Layering an explicit account-linking process on top means that wherever ambiguity exists, a deliberate, auditable step (not an automatic assumption) resolves the mapping. This follows standard federated identity best practices, including those outlined in SAML and OpenID Connect specifications. Option A is dangerous because it blends two separate authentication systems incorrectly. Knowing a local password doesn't prove the federated user is that local account holder — it could indicate a shared, guessed, or reused password, and it undermines the separation of identity providers. Option B compounds the problem rather than solving it. Sharing one account across multiple real people destroys individual accountability and creates serious authorization risks — session logs are a forensic tool, not an access-control mechanism. Option D is the most severe mistake: it treats successful authentication at the partner as blanket ownership of every name-matched local account, which could hand one user access to another person's data entirely. When you see federation questions, ask yourself: Is the identifier unique, trusted, and issuer-controlled? If yes, it's a safe mapping key. If it's user-supplied or non-unique, it's a vulnerability.

Question 9

A user authenticates through an identity provider and opens two federated applications. The user then signs out of the first application but can continue using the second application without entering credentials again.

What is the most likely explanation?

  1. The second application must have cached the user's identity-provider password when the initial sign-in occurred.
  2. Federation guarantees that signing out of one application cannot affect any other application session.
  3. The first application's local session ended, but the second application's session or the identity-provider session remained active. (correct answer)
  4. The first application revoked the federated trust relationship only for the user's current browser session.
Explanation: When studying federated identity and Single Sign-On (SSO), focus on how sessions work at multiple layers simultaneously: the identity provider (IdP) session and each application's own local session are distinct. Signing out of one application typically terminates only that application's local session — it doesn't automatically propagate a logout signal to the IdP or to other connected applications unless a global Single Log-Out (SLO) protocol is explicitly implemented and all parties honor it. This is exactly why C is correct. The user's second application maintains its own active session token, and the IdP session may still be alive as well. Neither was touched when the user signed out of the first application. The second application simply continues operating on its existing, valid session. A is wrong because federated systems are specifically designed so that applications never receive or cache the user's actual IdP password. Instead, they exchange tokens (like SAML assertions or OAuth/OIDC tokens) — the password stays with the IdP exclusively. B is wrong because it states an absolute guarantee that doesn't exist. Federation has no built-in rule preventing sign-out in one app from affecting others — it's a matter of implementation. Some systems do implement SLO, which propagates sign-out across all sessions. D is wrong because "revoking the federated trust relationship" is a configuration-level administrative action, not something a user-initiated sign-out triggers per browser session. That's a made-up mechanism conflating session termination with trust policy changes. As a study tip, remember: in federation questions, always think in layers — IdP session, application session, and token validity are all separate concerns that can behave independently.

Question 10

An organization requires multifactor authentication at its identity provider. Most applications use federation, but one application still permits users to sign in directly with a local username and password.

Which change would best support the goal of consistently enforcing the organization's MFA requirement?

  1. Disable or tightly restrict the application's local authentication path so users must authenticate through the identity provider. (correct answer)
  2. Retain local sign-in but require users to choose the same password they use at the identity provider.
  3. Allow local sign-in only when the identity provider's password policy is stronger than the application's policy.
  4. Configure the application to trust all successful local logins as if the identity provider had performed MFA.
Explanation: When you see a question about enforcing authentication policies across an organization, the core concept is policy consistency — specifically, eliminating bypass paths that let users sidestep security controls. MFA at an identity provider (IdP) only protects you if every authentication path routes through that IdP. A single local login bypass completely undermines the control. The strongest fix, as described in A, is eliminating the bypass itself. By disabling or restricting the application's local authentication path, you force all users through the IdP, where MFA is already enforced. This is the principle of closing the gap — you can't consistently enforce a policy that has exceptions baked into the architecture. B is a trap that conflates password synchronization with MFA. Requiring the same password across both paths doesn't add a second factor — it just creates password reuse risk while leaving MFA unenforced on the local path entirely. C introduces a conditional exception based on password policy strength, but password policy strength is irrelevant here. MFA is a factor count requirement, not a password complexity question. Allowing local logins under any condition still bypasses MFA. D is particularly dangerous — it essentially instructs the application to lie about authentication strength by treating a single-factor local login as if MFA occurred. This doesn't enforce MFA; it forges the claim that MFA happened. Study tip: On security exam questions, watch for answers that simulate a control versus answers that implement it. Anything that pretends a weaker authentication is equivalent to a stronger one (like D) is almost always a distractor designed to test whether you understand the difference between enforcing a policy and faking compliance with it.