Explanation:

The OAuth 2.0 Device Flow is a type of authorization flow that allows users to register an IoT device with limited display input or capabilities, such as a smart TV, a printer, or a smart speaker1. The device flow works as follows1:

👉 The device displays or reads out a verification code and a verification URL to the user.
👉 The user visits the verification URL on another device, such as a smartphone or a laptop, and enters the verification code.
👉 The user logs in to Salesforce and approves the device.
👉 The device polls Salesforce for an access token using the verification code. Salesforce returns an access token to the device, which can then access Salesforce APIs.

Explanation:

B. Use an AppExchange product to sync users from Active Directory to Salesforce.
AppExchange tools like Okta, OneLogin, or Azure AD Enterprise Apps support automated user provisioning (via SCIM or custom APIs) directly from Active Directory. They can handle creating, updating, and deactivating users in Salesforce, including assigning profiles, roles, and permissions, often with minimal coding required.

D. Use Identity Connect to sync users from Active Directory to Salesforce.
Salesforce's Identity Connect is a managed solution explicitly designed to sync users and their metadata from AD to Salesforce. It supports provisioning, deprovisioning, SSO, and mapping of AD groups to Salesforce roles and profiles—meeting UC’s requirement to avoid manual user setup in Salesforce

❌ Why A and C Are Not Optimal

A. Using custom REST API integration from AD to Salesforce would require building and maintaining a custom middleware layer. This approach is more complex and error-prone than leveraging established provisioning tools.

C. ADFS handles authentication (SSO), not user provisioning. It won’t automatically create or manage Salesforce user records, roles or profiles—only authenticate users.

💡 Summary Table

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:

These are the steps required to enable Salesforce as a SAML Identity Provider and use the App Launcher to access external applications. According to the Salesforce documentation1, you need to:

Enable Salesforce as a SAML Identity Provider with My Domain2.

Create a Connected App for each external application that you want to integrate with Salesforce3. Add each Connected App to the App Launcher with a Start URL that points to the external application1.

Option B is incorrect because setting up an Auth Provider is not necessary for SAML SSO. Auth Providers are used for OAuth SSO, which is a different protocol4. Option D is incorrect because Identity Connect is a tool for synchronizing user data between Active Directory and Salesforce, which is not related to SSO or App Launcher5.

References:

👉 1: App Launcher - Salesforce
👉 2: Enable Salesforce as a SAML Identity Provider
👉 3: Connected Apps Overview
👉 4: Identity Providers and Service Providers - Salesforce
👉 5: Identity Connect Overview

Explanation:

Leverage an existing org: UC1 already contains all users, so making it the Identity Provider (IdP) for the other Salesforce orgs (UC2–UC5) reduces cost and complexity versus purchasing a separate third-party IdP.

Just-In-Time (JIT) provisioning: By enabling SAML-based JIT provisioning in UC2–UC5, the orgs can automatically create or update Salesforce user accounts at first login—based on identity data sent from UC1—eliminating manual setup of users, profiles, and roles .

Minimal overhead: This architecture requires configuration only in existing Salesforce environments and no integration middleware or third-party tools. It scales easily when adding additional orgs or users.

Alternatives Not Recommended:

A & B (use third-party IdP) introduce extra licensing, integration, and maintenance overhead.

D (no JIT) would force manual user provisioning, defeating UC’s goal to simplify and centralize user management.

Explanation:

According to the Salesforce documentation1, OpenID Connect Token Introspection allows all OAuth connected apps to check the current state of an OAuth 2.0 access or refresh token. The resource server or connected apps send the client app’s client ID and secret to the authorization server, initiating an OAuth authorization flow. As part of this flow, the authorization server validates, or introspects, the client app’s access token. If the access token is current and valid, the client app is granted access.

Explanation:

The HTTP parameter that should be used when submitting a SAML request to the IdP to ensure the user is returned to the intended resource after authentication is RelayState. RelayState is an optional parameter that can be used to preserve some state information across the SSO process. For example, RelayState can be used to specify the URL of the resource that the user originally requested on the SP before being redirected to the IdP for authentication. After the IdP validates the user’s identity and sends back a SAML response, it also sends back the RelayState parameter with the same value as it received from the SP. The SP then uses the RelayState value to redirect the user to the intended resource after validating the SAML response. The other options are not valid HTTP parameters for this purpose. RedirectURL, DisplayState, and StartURL are not standard SAML parameters and they are not supported by Salesforce as SP or IdP.

Explanation:

To ensure secure communication between Salesforce and the on-premise application, the Identity Architect must enforce certificate-based authentication, where Salesforce presents a trusted certificate to the on-premise system. Here’s why Option C is the best approach:

1. Certificate Authority (CA)-Signed Certificate Ensures Trust
👉 A CA-signed certificate (unlike a self-signed one) is inherently trusted because it is issued by a recognized Certificate Authority (e.g., DigiCert, GlobalSign).
👉 The on-premise application can validate this certificate via its Truststore, which contains trusted CA root certificates.

2. Steps to Implement This Solution:
👉 Generate a CA-signed certificate in Salesforce (or obtain one from a trusted CA).
👉 Upload the certificate (public key) to the on-premise Truststore, ensuring the app only accepts requests with this certificate.
👉 Configure Salesforce to present this certificate when calling the on-premise endpoint (e.g., in Named Credentials or Apex callouts).

Why Not the Other Options?

👉 A (Self-signed certificate) → Not inherently trusted; requires manual Truststore updates and is less secure.
👉 B (Firewall IP whitelisting) → Does not enforce certificate-based authentication (only network-level security).
👉 D (Third-party certificate from Salesforce) → Misleading; Salesforce does not issue third-party certificates—they must be obtained from a CA.

Explanation:

Delegated Authentication is a mechanism in Salesforce that allows you to delegate login authentication to an external system (such as an on-premise Active Directory or another identity service). It works by having Salesforce make a web service call (either SOAP or REST) to the external authentication service during the login process.

Here are the correct capabilities:

B. It can connect to SOAP services. ✅
Delegated Authentication traditionally supports SOAP-based services. Salesforce sends a username and password to the delegated authentication endpoint, and expects a Boolean (true/false) response indicating authentication success.

C. It can be assigned by Profiles. ✅
Delegated Authentication is enabled at the Profile level. This allows Salesforce administrators to specify which users must use delegated authentication for login instead of standard Salesforce credentials.

D. It can connect to REST services. ✅
As of recent updates, REST support is also available via custom implementations, although SOAP is the most officially supported and common. Developers can configure a RESTful endpoint for Salesforce to use in delegating the login authentication.

❌ A. It can be assigned by Custom Permissions.
This is incorrect. Delegated Authentication cannot be assigned by Custom Permissions. It is controlled via Profiles, not permission sets or custom permissions.

Explanation:

Using the identity provider’s certificate to digitally sign and encrypt the payload, and using a custom login flow to retrieve sensitive data using an Apex callout without including the attributes in the assertion are two methods that can ensure that the sensitive data cannot be tampered with, nor accessible to anyone while in transit. Option A is not a good choice because using Salesforce’s certificate to encrypt the payload may not work, as Salesforce does not support encrypted SAML assertions. Option B is not a good choice because using Salesforce’s certificate to digitally sign the SAML assertion may not be necessary, as Salesforce does not validate digital signatures on SAML assertions. Also, using a mobile device management client on the users’ mobile devices may not be relevant, as it does not affect how the sensitive data is transmitted between the identity provider and Salesforce.

Explanation:

Configuring SSO to use the third-party portal as an identity provider is the best option to enable SSO between the portal and Salesforce. The portal can use OAuth as the protocol to authenticate users and redirect them to Salesforce. The other options are either not feasible or not relevant for this use case.

References:

Single Sign-On for Desktop and Mobile Applications using SAML and OAuth, Single Sign-On with SAML on Force.com

Explanation:

The two OAuth flows that support refresh tokens are Web server and User- Agent. According to the Salesforce documentation2, “The web server authentication flow and user-agent flow both provide a refresh token that can be used to get a new access token.” Therefore, option A and C are the correct answers.