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

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:

Why A (sign + encrypt) is correct:
In SAML, the IdP should digitally sign the assertion (integrity / anti-tamper) and the SP (Salesforce) should be configured to decrypt inbound encrypted assertions so sensitive attributes aren’t readable in transit via the user’s browser. In Salesforce SSO setup you upload/select an SP decryption certificate for encrypted assertions from the IdP.

Why D (don’t send the sensitive attributes; fetch server-to-server) is also correct:
If those attributes don’t need to traverse the browser, use a Login Flow that, after SAML login, performs an Apex/External Services callout to your IdP (or another internal API) to retrieve the sensitive data. This avoids exposing them in the SAML payload altogether and still enforces access policies before the session completes.

Why not B or C:
B: Salesforce (the SP) doesn’t sign assertions; the IdP signs. An MDM client doesn’t protect SAML attributes in the browser POST.
C: Encrypting with the IdP’s certificate means Salesforce can’t decrypt it; encryption must target the SP’s public key so only Salesforce can read it. Salesforce explicitly documents configuring SP decryption for encrypted assertions.

Explanation:

Northern Trail Outfitters (NTO) wants employees to log in to Salesforce Service Cloud using credentials from a third-party employee portal, which supports OAuth for authentication. The goal is to enable single sign-on (SSO) for a seamless experience. Let’s evaluate each option to determine the best approach for an identity architect:

A. Configure SSO to use the third-party portal as an identity provider: Incorrect.
While using the third-party portal as an Identity Provider (IdP) is feasible if it supports SAML or OpenID Connect (OIDC), the question specifies that the portal only supports OAuth. OAuth is an authorization protocol, not an authentication protocol like SAML or OIDC, and Salesforce requires an IdP to support SAML or OIDC for standard SSO configurations. The portal’s OAuth limitation makes it unsuitable as a traditional IdP for Salesforce SSO.

B. Create a custom external authentication provider: Correct.
Salesforce supports custom authentication providers, which allow integration with external systems for SSO using protocols like OAuth or OpenID Connect. Since the third-party portal supports OAuth, NTO can create a custom authentication provider in Salesforce using Apex to handle the OAuth flow (e.g., Authorization Code or Implicit flow). This involves configuring the portal as an OAuth provider, directing users to authenticate via the portal’s OAuth endpoint, and exchanging tokens to authenticate users in Salesforce. This approach enables seamless SSO by leveraging the portal’s OAuth credentials, meeting NTO’s requirements.

C. Add the third-party portal as a connected app: Incorrect.
A Connected App in Salesforce is used when Salesforce acts as the IdP or resource server, allowing external applications to access Salesforce data via OAuth or SAML. In this scenario, the third-party portal is the authentication source, not Salesforce, so defining the portal as a Connected App in Salesforce is not applicable. Connected Apps are for outbound integrations, not for using an external system’s credentials to log in to Salesforce.

D. Configure Salesforce for Delegated Authentication: Incorrect.
Delegated Authentication allows Salesforce to delegate user authentication to an external service via a custom web service (e.g., SOAP-based). However, the third-party portal only supports OAuth, not a custom web service protocol required for Delegated Authentication. Additionally, Delegated Authentication replaces Salesforce’s password-based login entirely, which may not align with the SSO goal and requires significant custom development on the portal side.

Why B:
A custom external authentication provider allows Salesforce to integrate with the third-party portal’s OAuth-based authentication, enabling employees to use their portal credentials for SSO into Salesforce. This leverages Salesforce’s extensible identity framework, supports the portal’s OAuth limitation, and ensures a seamless login experience with minimal changes to the existing portal.

References:
Salesforce Help: Create a Custom External Authentication Provider
Salesforce Help: External Authentication Providers
Trailhead: Identity for Developers
Salesforce Developer Docs: Custom Authentication Provider Example

Explanation:

A. Web server:
This is the standard and most secure OAuth 2.0 flow for applications that can securely store a client secret, such as web server-based applications. In this flow, an authorization code is exchanged for an access token and a refresh token. The refresh token can then be used to obtain new access tokens without requiring the user to log in again, providing a better user experience for long-lived sessions.

C. User-Agent:
This flow is designed for clients like mobile or desktop apps that cannot securely store a client secret. While historically it did not grant refresh tokens, modern implementations and updates, including Salesforce's own, now support refresh tokens for this flow. The connected app must explicitly request the refresh_token scope, and the refresh token is delivered as a URL fragment to the redirect URI.

Incorrect Answer Rationale:

B. JWT bearer token:
The OAuth 2.0 JWT Bearer Token flow is a server-to-server integration flow that uses a JSON Web Token (JWT) to obtain an access token without user interaction. This flow is designed for non-interactive scenarios and does not return a refresh token. Instead, a new JWT is generated and presented to the token endpoint each time a new access token is needed.

D. Username-password:
The OAuth 2.0 Username-Password flow is an older, less secure flow where the application collects the user's username and password and sends them directly to the authorization server to exchange for an access token. This flow is highly discouraged due to the security risks of transmitting user credentials. Furthermore, while it can return a refresh token, Salesforce recommends against its use, and it is not typically considered in an architectural evaluation focused on modern, secure OAuth flows.

Salesforce documentation:
OAuth 2.0 Web Server Flow: Details the web server flow, including its capability to issue refresh tokens.
OAuth 2.0 User-Agent Flow: Explains how the user-agent flow works and mentions its support for refresh tokens.
OAuth 2.0 JWT Bearer Token Flow: Clarifies that this flow does not support refresh tokens.
OAuth 2.0 Username-Password Flow: Details the username-password flow and the security risks associated with it.

Explanation:

Salesforce Identity Connect is a specialized application that synchronizes user accounts and attributes between an on-premise Microsoft Active Directory (AD) and Salesforce. Its core functions are synchronization and lifecycle management.

C. Support multiple orgs connecting to multiple Active Directory servers. This is a key feature of Identity Connect. It can be configured in a hub-and-spoke model, where a single Identity Connect instance can synchronize users from multiple Active Directory forests/domains to multiple Salesforce orgs. This is essential for large enterprises with complex directory structures.

D. Automated user synchronization and de-activation. This is the primary purpose of Identity Connect. It provides automated, real-time (or scheduled) synchronization of user profiles, roles, and other attributes from AD to Salesforce. Crucially, it also handles de-activation: when a user is disabled or deleted in AD, Identity Connect can automatically deactivate the corresponding user in Salesforce, which is a critical security function.

Why the other options are incorrect:

A. Synchronization of Salesforce Permission Set Licence Assignments. This is incorrect. Identity Connect synchronizes standard user attributes from AD (like username, email, profile, role). However, the assignment of Permission Set Licenses is a Salesforce-specific licensing function that is not controlled by or synchronized from Active Directory. This is managed within Salesforce.
B. Supports both Identity-Provider-Initiated and Service-Provider-Initiated SSO. This is incorrect. Identity Connect is not an SSO product. It is strictly a user provisioning and de-provisioning tool. SSO (whether IdP-initiated or SP-initiated) is handled by separate protocols and configurations, such as SAML or OpenID Connect, often involving a federation service like ADFS. Identity Connect works alongside SSO solutions to ensure user accounts are synchronized, but it does not perform the SSO authentication itself.

Architectural Consideration:
Identity Connect solves the problem of user lifecycle management between an on-premise directory and the cloud. It ensures that user access in Salesforce is directly tied to their status in the corporate directory, enforcing a "joiner, mover, leaver" process automatically. This reduces administrative overhead and improves security.

Reference:
Salesforce Help: "Salesforce Identity Connect" - This documentation outlines its purpose, stating it "synchronizes your Microsoft Active Directory with your Salesforce organization to automate user creation, updates, and deactivations." It also discusses the multi-org and multi-directory capabilities.

Explanation:

To implement Social Sign-On for Salesforce Experience Cloud using providers like Facebook and LinkedIn, an Identity Architect should follow these core steps:

B. Create authentication providers for both Facebook and LinkedIn ✅
Salesforce provides built-in support for popular social identity providers. You must configure Authentication Providers under Setup > Auth. Providers for each service (Facebook and LinkedIn), specifying their client ID, client secret, authorize endpoint, etc.

C. Check "Facebook" and "LinkedIn" under Login Page Setup ✅
After the Auth Providers are set up, you can customize the login page in the Login & Registration section of the Experience Builder to display social login buttons for Facebook and LinkedIn.

E. Update the default registration handlers to create and update users ✅
You need to provide an Apex Registration Handler class to control how new users are created or updated when logging in via social accounts. This is crucial to link the external identity to Salesforce users and define user profiles, roles, etc.

❌ Incorrect Options

A. Register both Facebook and LinkedIn as connected apps
Incorrect: Connected Apps are used for OAuth clients or integrations, not required for social sign-on using Auth Providers.

D. Enable "Federated Single Sign-On Using SAML"
Incorrect: SAML is not used for social login like Facebook or LinkedIn, which use OAuth 2.0.

Explanation:

To automate user provisioning and deprovisioning into Salesforce from an external system, one of the most scalable and Salesforce-native solutions is SAML Just-in-Time (JIT) provisioning.

With SAML JIT:
👉 When a user attempts to log in via SAML Single Sign-On, Salesforce receives a SAML assertion from the Identity Provider (IdP).
👉 If the user does not exist in Salesforce, it is automatically created with the attributes provided in the assertion (e.g., username, email, profile, role).
👉 If the user already exists, the user record is updated with new values as defined in the mapping rules.
👉 It requires no pre-setup of user records in Salesforce—perfect for real-time provisioning and maintenance

❌ Incorrect Options:

A. Call SOAP API upsert on User object
Technically possible, but not the best practice for real-time identity lifecycle integration. Also requires custom integration and higher maintenance.
C. Run registration handler on incoming OAuth responses
Registration handlers are used with Auth Providers, but not standard for automated enterprise provisioning. This is better suited for social login or Experience Cloud.
D. Call OpenID Connect (OIDC)-userinfo endpoint with a valid access token
This fetches user information from an IdP—it doesn’t provision users into Salesforce.

Explanation:

Delegated Authentication allows Salesforce to delegate user authentication to an external service (e.g., a custom web service) instead of using Salesforce’s native password-based authentication. The architect must consider key aspects of its implementation to ensure it meets security and functionality requirements. Let’s evaluate each option:

A. The authentication web service can include custom attributes: Correct.
In Delegated Authentication, the external authentication web service (hosted by the organization) can process custom attributes sent by Salesforce during the authentication request (e.g., user ID, organization ID, or custom fields). This allows the external service to use additional context for authentication decisions, such as verifying user-specific data or applying custom logic, making it a key consideration for implementation.

B. It can be used to authenticate API clients and mobile apps: Incorrect.
Delegated Authentication is designed for interactive user logins (e.g., via the Salesforce UI) and is not typically used for API clients or mobile apps. API clients and mobile apps generally use OAuth flows (e.g., Web Server, User-Agent) or other protocols like JWT Bearer for authentication, as Delegated Authentication relies on a SOAP-based web service that is not optimized for programmatic or non-browser-based access.

C. It requires trusted IP ranges at the User Profile level: Incorrect.
Delegated Authentication does not mandate trusted IP ranges at the user profile level. Trusted IP ranges are a separate Salesforce security feature used to bypass multi-factor authentication (MFA) or restrict login access, but they are not a requirement for implementing Delegated Authentication. The external authentication service handles credential validation, independent of IP-based restrictions.

D. Salesforce servers receive but do not validate a user’s credentials: Correct.
In Delegated Authentication, Salesforce receives the user’s credentials (e.g., username and password) but forwards them to the external authentication web service for validation instead of checking them against Salesforce’s own database. Salesforce trusts the external service’s response (true/false) to authenticate the user, making this a critical consideration for security and implementation.

E. Just-in-Time Provisioning can be configured for new users: Incorrect.
Just-in-Time (JIT) Provisioning is specific to SAML-based SSO or OpenID Connect, where user attributes in a SAML assertion or ID token are used to create or update users in Salesforce. Delegated Authentication does not support JIT provisioning, as it focuses solely on credential validation and does not pass user attributes for provisioning purposes.

Why A and D:
A is critical because the ability to include custom attributes in the authentication request allows flexibility in how the external service validates users.
D is fundamental to Delegated Authentication’s mechanism, as Salesforce delegates credential validation to the external service, impacting security and integration design.

References:
Salesforce Help: Delegated Authentication Overview
Salesforce Help: Configuring Delegated Authentication
Trailhead: Identity Basics

Explanation:

Why these:
B. Require high assurance sessions for the Connected App. In the Connected App’s policies, require a High Assurance session. Map MFA to High Assurance in Session Settings, so the app is usable only after strong auth (e.g., MFA).
C. Use Google Authenticator (TOTP) as an extra factor. Salesforce supports MFA via TOTP apps such as Google Authenticator; using MFA for this sensitive, internal-only billing app is an appropriate control.

Why not:
A. Disallow SSO — SSO is typically beneficial (central policies, MFA at IdP). Disallowing it reduces control and user experience.
D. Set login IP ranges to internal network — Users are “commonly out of the office,” so restricting to internal IPs would block legitimate mobile access.

Explanation:

The requirement is for users to use their AD password for the Salesforce mobile app, but a VPN is not available. This means the authentication cannot happen directly against the on-premise AD server. The solution must bridge the on-premise AD world with the cloud-based mobile app.

A. Active Directory Password Sync Plugin: This is a specific component that works with Identity Connect. The Password Sync Plugin is installed on the on-premise Active Directory servers. Its job is to capture password changes as they happen in AD and securely transmit a one-way hash of the new password to Salesforce. This allows Salesforce to store a version of the password that it can validate against, without ever knowing the actual plaintext password.

D. Salesforce Identity Connect: Identity Connect is the central orchestrator for this solution. It is the application that synchronizes user accounts and, when combined with the Password Sync Plugin, password hashes from on-premise AD to Salesforce. It ensures that when a user's password is changed in AD, that change is reflected in Salesforce. This allows the user to enter the same AD password directly into the Salesforce mobile app, as Salesforce can now validate it against the synchronized hash.

Why the other options are incorrect:
B. Configure Cloud Provider Load Balancer: This is completely unrelated to identity and access management. A load balancer distributes network traffic across servers and has no role in synchronizing passwords or enabling authentication.
C. Salesforce Trigger & Field on Contact Object: This is a technical distractor. While you could theoretically build a completely custom system using Apex triggers and a custom field to store a password, this would be a massive security anti-pattern. It would involve handling and storing passwords in plaintext or with weak encryption, which is highly insecure and violates best practices. Salesforce provides supported, secure tools (Identity Connect) for this exact purpose.

Architectural Consideration:
The combination of Identity Connect and the Password Sync Plugin is the supported and secure method to achieve AD password synchronization for cloud authentication. It avoids the need for a VPN or exposing the on-premise AD server to the internet. The password hash is synchronized securely, and the actual plaintext password never leaves the user's device or the on-premise network during the capture process.

Reference:
Salesforce Help: "How Password Synchronization Works" - This documentation explains the role of both the Password Sync Plugin and Identity Connect in enabling users to log in with their network password.