Identity-and-Access-Management-Architect Practice Test Questions

Explanation:

When User Provisioning is enabled for a Connected App, Salesforce can synchronize user data (such as profiles, roles, and permissions) with a third-party system. However, role synchronization is not automatic—it must be explicitly configured in the User Provisioning Settings.

Here’s why Option B is correct:

👉 Provisioning Requires Explicit Field & Operation Mapping
👉 Under User Provisioning Settings, administrators must define which user attributes (e.g., Role, Profile, Email) should be synced.
👉 If the "Role" field was not mapped or the "Update" operation was not enabled, role changes in Salesforce will not propagate to the third-party system.

Why the Other Options Are Incorrect:

👉 A. User Provisioning does support role sync → But it must be configured manually.
👉 C. An unmonitored Approval queue → Would delay provisioning but not block role sync specifically.
👉 D. Role hierarchy depth → Does not affect provisioning sync capabilities.

Conclusion:

The issue stems from missing field/operation mappings in User Provisioning Settings. To fix this, UC’s admin must:
✔ Map the RoleId field.
✔ Ensure "Update" operations are enabled for role changes.

Explanation:

Configuring Mobile App settings in connected app and Salesforce as identity provider for non-Salesforce internal apps is the best way to meet the requirements with the privately distributed mobile app. The Mobile App settings allow users to download the app from a private URL and use it with Salesforce credentials. The identity provider settings allow users to access other internal apps with SSO using Salesforce as the IdP. The other options are either not feasible or not optimal for this use case.

References:

Mobile App Settings, Single Sign-On for Desktop and Mobile Applications using SAML and OAuth

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.