SY0-701 Question 352
Single answerSingle sign-on (SSO), Lightweight Directory Access Protocol (LDAP), Open authorization (OAuth), Security Assertions Markup Language (SAML)A company is integrating a new cloud-based human resources application with its existing on-premises identity infrastructure. Employees should sign in to the HR application using their existing corporate credentials and should not need a separate username and password. The security team wants the cloud application to trust authentication performed by the company's internal identity provider, while still allowing centralized account management in the corporate directory. Which of the following is the BEST solution?
- A
Configure LDAP directly from the cloud HR application to the internal directory so the application can perform authentication over the internet
- B
Implement SAML-based SSO between the internal identity provider and the cloud HR application, using the directory as the authoritative identity source
- C
Use OAuth to authenticate users directly to the cloud HR application with their corporate passwords
- D
Create local accounts in the HR application and synchronize passwords nightly from the corporate directory
Show answer and explanation
Correct answer: B
Explanation
The best answer is to implement SAML-based SSO. In a typical enterprise federation model, the organization's internal directory, such as Active Directory or another LDAP-backed directory, remains the authoritative source for user identities. An identity provider authenticates the user against that directory and then issues a SAML assertion to the cloud application, which acts as the service provider. This allows users to access the SaaS application with existing corporate credentials and avoids maintaining separate passwords in the cloud app.
This distinction is important on Security+:
- LDAP is used to access and manage directory services, but it is not itself the preferred federation method for internet-facing SaaS SSO.
- SSO is the business or access outcome, while SAML is one of the protocols commonly used to implement SSO for web applications.
- OAuth is mainly for delegated authorization, such as allowing one service to access another service's resources without sharing credentials. For authentication, OpenID Connect extends OAuth 2.0, but that is different from plain OAuth.
This aligns with common vendor and standards guidance, including OASIS documentation for SAML and standard enterprise identity architecture practices for federated access to SaaS platforms.
- A. Incorrect.
This is not the best solution. LDAP is a directory access protocol commonly used to query and manage directory information such as users and groups, but exposing LDAP authentication directly from an internal directory to a cloud application is generally not the preferred design for federated access. It can increase attack surface, complicate firewall and security controls, and does not provide the federated assertion model typically used for cloud single sign-on. A candidate might choose this because LDAP is associated with directories and authentication, but LDAP alone is not the standard approach for browser-based federation to SaaS applications.
- B. Correct.
This is correct. SAML is commonly used for enterprise single sign-on to web-based cloud applications. In this scenario, the company can keep identities in its internal directory, authenticate users through its identity provider, and send signed SAML assertions to the cloud HR application as the service provider. This meets the requirement for employees to use existing corporate credentials without creating separate application-specific passwords, while maintaining centralized account management.
- C. Incorrect.
This is incorrect because OAuth is primarily an authorization framework, not an authentication protocol for directly validating a user's corporate password to a SaaS application. OAuth is designed to grant limited access to resources on a user's behalf, often through access tokens. While related technologies such as OpenID Connect add authentication capabilities on top of OAuth 2.0, OAuth by itself is not the best answer for this classic enterprise web SSO federation scenario.
- D. Incorrect.
This is not the best solution. Creating local accounts with password synchronization increases administrative overhead, duplicates identities, and introduces additional security risks related to password handling and synchronization. It also does not provide true federated SSO because the cloud application is still maintaining separate local accounts rather than trusting the corporate identity provider at login time. Someone might choose this thinking it preserves central management, but it is weaker than federation and less aligned with best practices.