Explanation:

Universal Containers (UC) wants to ensure SAML-based SSO works seamlessly for users accessing Salesforce via the Salesforce1 mobile app. Here’s why Options B and C are the best recommendations:

1. Option B: Configure the Salesforce1 App to Use My Domain URL
👉 For SAML SSO to work on the Salesforce1 mobile app, users must log in via My Domain (e.g., yourcompany.my.salesforce.com).
👉 If users try to log in directly through the app without My Domain, Salesforce defaults to username/password authentication instead of SAML redirection.
2. Option C: Use the Existing SAML-SSO Flow Along with User Agent Flow
👉 The User Agent Flow (also called the "WebView" flow) is the recommended OAuth flow for SAML SSO on mobile apps.
👉 It allows the Salesforce1 app to:
✔ Open a browser session (or embedded WebView) for SAML authentication.
✔ Redirect users to the IdP for login, then return them to the app with an OAuth token.

Why Not the Other Options?

A. Embedded Web Browser → While configuring My Domain is necessary, this option alone does not address the OAuth flow requirement for SAML SSO on mobile.
D. Web Server Flow → Designed for server-to-server authentication (not mobile SSO).

Explanation:

Login Forensics is a feature in Salesforce designed specifically to help security teams detect suspicious login behavior. It provides advanced insights such as:

📊 Average number of logins per user
🚨 Users who logged in more than the average
🌙 Logins during non-business hours
🌍 Geographic anomalies (e.g., logins from unexpected countries)

This makes it the ideal tool for identifying potential fraudulent activity or compromised accounts in a large organization like one with 15,000 employees.

❌ Why the other options fall short:
B. Login Report:
Offers basic login data but lacks advanced analytics like averages or time-based anomalies.
C. Login Inspector:
Used for debugging login issues during development—not for security analysis.
D. Login History:
Provides raw login data (IP, time, status), but requires manual analysis and doesn’t highlight patterns or anomalies.

🔗 Reference:
Salesforce Login Forensics Overview

Explanation:

Why this is correct
Mapping the SSO IdP to High Assurance tells Salesforce to trust the IdP’s MFA. When a user signs in via SSO (where MFA already occurred), Salesforce grants a High Assurance session without prompting again, so users see only one MFA challenge.
Requiring High Assurance at login on employee profiles ensures that direct username+password logins to Salesforce also meet High Assurance—i.e., Salesforce will prompt for MFA once in that path. Net result: one MFA prompt for either login method.

Why the other options are not ideal
A. Permission set “MFA for User Interface Logins.”
This forces Salesforce’s own MFA on all UI logins, including SSO. Because the IdP already did MFA, users coming via SSO can get a second, duplicate MFA prompt, violating the “single prompt” requirement. Salesforce specifically recommends using the IdP’s MFA with High Assurance mapping to avoid duplicate prompts.
B. Custom Login Flow enforcing MFA.
Login Flows can add extra challenges, but here it would layer an additional MFA on top of the IdP’s MFA for SSO users, again risking double prompts. It’s more complex than necessary compared to Session Security Levels + IdP High Assurance mapping.
C. Enable “MFA for User Interface Logins” org-wide.
This covers direct Salesforce logins only; it doesn’t address SSO behavior or unify assurance levels. You still need the High Assurance mapping to ensure Salesforce doesn’t add a second prompt for SSO and to make your assurance policy explicit.

Reference:
Use your IdP’s MFA for SSO logins (prevents duplicate prompts by granting High Assurance).
Session Security Levels & High Assurance (how to require High Assurance and control policies).
Require High-Assurance Session Security for Sensitive Access (how to configure High Assurance in Setup).
Org-wide “Require MFA for all direct UI logins” (scope limited to direct Salesforce logins).

Explanation:

When Salesforce Delegated Authentication is enabled, the external system (in this case, the enterprise LDAP server) becomes the sole authority for validating user passwords. Salesforce delegates the authentication check to this external system and does not store or manage the password itself.

Let's evaluate each option:

D. Users can change it on the enterprise LDAP authentication portal. This is the correct and only viable method. Since the LDAP server is the "only point for user authentication," it is the system of record for the user's password. Any password change must occur within that system. The enterprise likely has an existing self-service portal or process for users to change their corporate/network passwords, and this is the process they must use.

A. Users once logged In, can go to the Change Password screen in Salesforce. This is incorrect. When Delegated Authentication is active, the "Change Your Password" option in Salesforce is disabled and hidden from users. Salesforce cannot change a password that it does not manage or store.

B. Users can click on the "Forgot your Password" link on the Salesforce.com login page. This is incorrect. The "Forgot Your Password" functionality in Salesforce is used to reset a password that is stored within Salesforce. Since authentication is delegated to the LDAP server, this Salesforce feature is bypassed and will not work. The user would receive an error or the process would fail.

C. Users can request the Salesforce Admin to reset their password. This is incorrect. A Salesforce administrator cannot reset a password that is managed in an external LDAP directory. Their ability to reset passwords is only for the local Salesforce user store, which is not being used for authentication in this configuration.

Key Takeaway:
The core principle of Delegated Authentication is that the external system is the master for password validation. Therefore, all password lifecycle management—including creation, changes, and resets—must be handled by that external system. Salesforce acts only as a relying party.

Reference:
Salesforce Help: "Delegated Authentication"
The documentation implies this by stating that the external service is responsible for authenticating the user's credentials. It does not provide a mechanism for Salesforce to modify those external credentials. The design inherently means password management remains with the delegated service.

Explanation:

Universal Containers (UC) wants to store user credentials in their custom employee hub application on AWS and enable these users to access Salesforce via authentication and authorization. The goal is to configure AWS to act as the identity provider (IdP) for Salesforce, allowing seamless SSO. Let’s evaluate the options:

B. Configure AWS as an OpenID Connect Provider: Correct.
AWS supports OpenID Connect (OIDC) through services like Amazon Cognito, which can be configured as an OIDC IdP. Salesforce supports OIDC for SSO, allowing AWS to authenticate users and provide identity assertions to Salesforce (acting as the Service Provider). This setup enables users to log in via AWS credentials and access Salesforce without separate authentication, meeting UC’s requirements.

A. Configure the custom employee app as a connected app: Incorrect.
A Connected App is a Salesforce configuration for integrating external applications with Salesforce, typically using OAuth or SAML. Configuring the AWS app as a Connected App would allow Salesforce users to access the AWS app, not the other way around (AWS authenticating Salesforce users).

C. Create a custom external authentication provider: Incorrect.
Salesforce’s external authentication provider framework is used for integrating with external IdPs via OpenID Connect or SAML. While AWS could be configured as an OIDC provider (as in option B), creating a custom authentication provider is unnecessary and overly complex, as AWS Cognito already supports OIDC natively.

D. Develop a custom Auth server in AWS: Incorrect.
Building a custom authentication server in AWS is possible but unnecessary, as AWS Cognito provides a robust, standards-based OIDC solution. This option adds complexity and maintenance overhead compared to using AWS’s existing OIDC capabilities.

Reference:
Salesforce Help: Set Up an OpenID Connect Provider
AWS Documentation: Amazon Cognito as OIDC Provider