SY0-701 Question 351
Single answerFederationA company is acquiring a smaller business and needs users from both organizations to access a shared SaaS project management platform using their existing corporate credentials. The security team wants to avoid creating separate accounts in the SaaS application, reduce password sprawl, and ensure each company continues managing its own user lifecycle and authentication policies. Which solution best meets these requirements?
- A
Configure a federation trust between the organizations' identity providers and the SaaS provider so authentication assertions are accepted across domains
- B
Create local accounts for all acquired-company users in the SaaS platform and require periodic password synchronization
- C
Deploy a shared LDAP directory that both companies fully administer for all authentication to the SaaS platform
- D
Use a site-to-site VPN between the companies so the SaaS provider can authenticate all users against the acquiring company's internal domain
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use federation between the organizations' identity providers and the SaaS provider. In a federation model, trust is established so an external service accepts authentication assertions from a trusted identity provider. This enables SSO, reduces the need for separate credentials, and allows each organization to continue enforcing its own authentication and account lifecycle policies. From a Security+ perspective, federation is especially valuable in B2B, merger, acquisition, and partner-access scenarios because it supports centralized identity management without merging directories or creating duplicate accounts. Common standards include Security Assertion Markup Language (SAML) and OpenID Connect (OIDC), both widely used for federated access to SaaS applications. Guidance from NIST on digital identity and federation concepts, such as NIST SP 800-63, aligns with this approach by distinguishing federated identity from local account management and emphasizing trusted assertions between identity systems.
- A. Correct.
Correct. Federation allows separate organizations or security domains to establish trust so users can authenticate with their home identity provider and access external services without needing separate application-specific accounts. In practice, this is commonly implemented with standards such as SAML or OpenID Connect for single sign-on (SSO). This approach supports the requirement that each company maintains control over its own identities, authentication methods, and deprovisioning while reducing password sprawl.
- B. Incorrect.
Incorrect. Creating local SaaS accounts increases administrative overhead and password sprawl, which directly conflicts with the stated goals. Password synchronization is also not the same as federation; it duplicates credential management rather than establishing trust between identity providers. This is a common misconception because both approaches can let users sign in, but only federation preserves centralized identity control in each organization.
- C. Incorrect.
Incorrect. A shared LDAP directory would require major operational integration and shared administration that the scenario does not require. It also reduces separation between the two organizations' identity stores and may complicate governance during an acquisition. Federation is designed specifically to enable cross-domain access while allowing each party to retain its own identity infrastructure.
- D. Incorrect.
Incorrect. A site-to-site VPN provides network connectivity, not identity federation. Even with connectivity, the SaaS provider typically authenticates users through supported identity standards rather than direct authentication to an internal domain across a VPN. This distractor reflects a common misunderstanding that network trust and identity trust are interchangeable; they are not.