Explanation:

When building a business case for purchasing a third-party Identity Provider (IdP), the architect should focus on the core enterprise security and productivity benefits that such a solution provides.
One of the key advantages of an IdP is that it enables centralized authentication across multiple applications (✅ Option A).
Rather than users managing separate credentials for each business app, the IdP can act as a single source of authentication, streamlining access and improving security. This is especially valuable for organizations like Universal Containers that use multiple internal and external apps — including Salesforce — and want a single sign-on (SSO) experience.

Another major benefit is the ability to centralize password policies across the enterprise (✅ Option D).
With an IdP, organizations can enforce consistent password complexity, expiration, and MFA policies for all connected applications. This reduces administrative overhead, increases security, and ensures compliance with IT and regulatory standards. These two capabilities — centralized authentication and centralized password policy enforcement — are foundational to modern identity and access management.

The other options, while related to identity, are less relevant or not core to IdP functionality:

Option B (authenticating social media accounts) pertains more to consumer identity providers (like Facebook or Google) than enterprise-grade IdPs.

Option C (storing credentials) is more of a password vault feature, not a function of a true SAML/OIDC-based IdP, which relies on token-based authentication, not credential storage.

Explanation:

Salesforce mobile applications (like the Salesforce1/Lightning Mobile App) do not directly use the SAML protocol itself. Instead, they use OAuth 2.0 flows for authorization. For SAML SSO to work on mobile, the flow is as follows:

Salesforce1 App Redirects: The mobile app starts the OAuth flow, which redirects the user's embedded browser to the Salesforce login page.
My Domain is Essential (D): The login request must be sent to the org's custom My Domain URL (https://mydomain.lightning.force.com or https://mydomain.my.salesforce.com) rather than the generic instance URL (https://na99.salesforce.com). My Domain is mandatory to enable the custom login page that includes the SSO authentication provider button. Therefore, the app needs to be configured to use this URL.
SSO Authentication (B): When the My Domain login page loads in the app's embedded web browser, the user is presented with the option to log in using the external Identity Provider (IDP) via the configured SSO button. The embedded browser is then responsible for the actual SAML communication (the redirect to the IDP, the SAML assertion, etc.).

A. Use the existing SAML SSO flow along with user agent flow. The Salesforce mobile app uses an OAuth flow, specifically the OAuth 2.0 User-Agent Flow (or a similar hybrid flow for native apps) to get an access token. While the flow internally uses a SAML-based authentication by redirecting to the SSO-enabled login page, simply stating "use user agent flow" is incomplete and is a description of the OAuth component, not the necessary configuration step to enforce SAML.

C. Use the existing SAML SSO flow along with Web server flow. The OAuth 2.0 Web Server Flow is used for web-based or desktop applications that can securely store a Consumer Secret, which is not the typical pattern for a publicly distributed mobile app like Salesforce1.

B & D. Configure the embedded Web browser/Salesforce1 app to use My Domain URL. These are the critical configuration steps. Setting the mobile app to use the My Domain URL ensures the user lands on the proper login page that has been configured to display the SAML Single Sign-On button. This successfully forces the user through the existing SAML SSO process.

Explanation:

Why A is Correct:
My Domain provides a consistent, custom URL structure (e.g., https://company.my.salesforce.com) that is essential for resource deep linking in SAML SSO. The SAML RelayState parameter can include a deep link to a specific Salesforce resource (e.g., a record or page), and My Domain ensures these URLs are reliable and secure. This is particularly important in SSO scenarios where users need to be directed to specific content after authentication.
Reference: Salesforce Help: Deep Linking with SAML – Discusses how RelayState is used for deep linking in SAML SSO, which relies on My Domain.

Why C is Correct:
My Domain is a prerequisite for configuring SAML SSO in Salesforce, including for the Salesforce Mobile App (formerly Salesforce1). It defines the secure endpoint (e.g., /services/auth/saml) that the IdP communicates with during the SAML SSO process. For mobile users, My Domain ensures that SAML assertions are correctly routed, enabling seamless SSO authentication.
Reference: Salesforce Help: Set Up SAML for Mobile Apps – Confirms that My Domain is required for SAML SSO in mobile contexts.

Why B is Incorrect:
The App Launcher is a Lightning Experience feature that organizes app access but is not directly involved in the SAML SSO authentication process. While My Domain is required for Lightning Experience, the App Launcher’s functionality is unrelated to SAML SSO configuration or execution.

Why D is Incorrect:
Login Forensics is a security monitoring feature that analyzes login events, but it is not a direct component of the SAML SSO authentication flow. My Domain supports the broader security framework, but Login Forensics operates independently of SAML-specific processes.

References

Salesforce Documentation:
My Domain Overview – Explains My Domain’s role in enabling features like SSO and deep linking.
SAML Single Sign-On – Details SAML SSO configuration, including the requirement for My Domain and support for deep linking via RelayState.
Salesforce Mobile App SSO – Covers SSO setup for mobile apps, emphasizing My Domain’s role.
Login Forensics – Describes Login Forensics, which is not directly tied to SAML SSO.
Trailhead:
Identity Basics – Covers My Domain and SSO fundamentals.
Single Sign-On for External Apps – Discusses SAML SSO and mobile app integration.

Explanation:

The goal is to increase security for a custom mobile app accessed by users who are outside the corporate network.

B. Require High Assurance sessions in order to use the Connected App:
In Salesforce, you can configure Session Policies for a Connected App.
By requiring a "High Assurance" session, you force users to have already authenticated with a higher level of security (like Multi-Factor Authentication) before being granted access to the connected app. This is a best practice for securing access to a specific, high-risk application.
D. Use Google Authenticator as an additional part of the login process:
Google Authenticator is a common Time-based One-Time Password (TOTP) application used to implement Multi-Factor Authentication (MFA).
MFA is a fundamental security requirement and best practice, as it requires the user to provide two or more verification factors, which is critical for users accessing the system from mobile devices outside the secure corporate perimeter. This recommendation directly addresses the need for a properly secured login process.

Why the Other Options are Less Appropriate
A. Disallow the use of Single Sign-on for any users of the mobile app:
SSO can be a secure authentication method, especially when paired with strong controls like MFA. Disallowing it unnecessarily adds complexity for users and doesn't inherently make the application more secure than a properly configured SSO with MFA.
C. Set Login IP Ranges to the internal network for all of the app users Profiles:
This is not a viable solution for a mobile app used by employees who are "commonly out of the office." Since their IP addresses will constantly change (using mobile data, Wi-Fi hotspots, etc.), restricting login IP ranges to the internal network would effectively block most of their access. IP restriction in the connected app settings is more flexible, but locking it down to a single internal network is counterproductive for a mobile workforce.

Explanation:

When an architect decides to use self-signed certificates for a system-to-system integration, they must understand the key difference between these and certificates issued by a trusted Certificate Authority (CA). A certificate from a trusted CA is already included in the truststore of most operating systems and browsers, which means the trusting party automatically trusts the certificate.

However, a self-signed certificate has no external verification. The entity creating the certificate is both the issuer and the subject. Therefore, the trusting party (e.g., a Salesforce org, an application server, etc.) must manually obtain and install a copy of this specific self-signed certificate into its own truststore so it knows to trust it.

This manual process introduces significant maintenance overhead:
Initial Setup: The architect must ensure that the certificate is securely transferred and correctly installed on every system that needs to trust the service.
Expiration Management: Unlike CA-issued certificates that have a clear lifecycle, self-signed certificates require the administrator to manually track their expiration and ensure they are replaced and re-distributed before they expire.
Scale and Distribution: In a large or distributed environment, this manual process becomes unmanageable and error-prone, making it a poor choice for large-scale deployments.

Why Other Options Are Incorrect ❌
A. Use of self-signed certificate leads to lower maintenance for trusted party because multiple self-signed certs need to be maintained. This is incorrect. The trusted party (the one issuing the self-signed cert) still has to manage the certificates and ensure they are updated. The fact that multiple certificates might be needed for different trusting parties can increase, not lower, maintenance.
B. Use of self-signed certificate leads to higher maintenance for trusted party because they have to act as the trusted CA. While the trusted party technically acts as its own CA by signing the certificate, this doesn't inherently lead to higher maintenance in the same way it does for the trusting party. The trusting party bears the burden of manual trust management on their end.
C. Use of self-signed certificate leads to lower maintenance for trusting party because there is no trusted CA cert to maintain. This is the opposite of the truth. The trusting party has to perform a manual maintenance task (adding the certificate to its truststore) that it would not have to do if the certificate was signed by a publicly trusted CA.