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:

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.

Explanation:

The two statements that are capabilities of Identity Connect are:

It supports both identity-provider-initiated and service-provider-initiated SSO. Identity Connect is a desktop application that integrates Salesforce with Microsoft Active Directory (AD) and enables single sign-on (SSO) between the two systems. Identity Connect supports both identity-provider-initiated SSO, which is when the user starts at the AD site and then is redirected to Salesforce with a SAML assertion, and service-provider-initiated SSO, which is when the user starts at the Salesforce site and then is redirected to AD for authentication.

It enables automated user synchronization and deactivation. Identity Connect allows administrators to synchronize user accounts and attributes between AD and Salesforce, either manually or on a scheduled basis. Identity Connect also allows administrators to deactivate user accounts in Salesforce when they are disabled or deleted in AD, which helps maintain security and compliance.

The other options are not capabilities of Identity Connect. Identity Connect does not support synchronization of Salesforce permission set license assignments, as these are not related to AD attributes. Identity Connect does not support multiple orgs connecting to multiple AD servers, as it can only connect one Salesforce org to one AD domain at a time.

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 offload user authentication to an external web service (typically hosted on-premises or in a private cloud). Here are the two key considerations:

A. Custom Attributes in Authentication Web Service
👉 The external authentication service can include custom attributes (e.g., department, role) in its response.
👉 These attributes can be mapped to Salesforce user fields (e.g., Profile, Permission Sets) for dynamic access control.

D. Salesforce Does Not Validate Credentials
👉 Salesforce forwards the user’s credentials to the external service but does not validate them itself.
👉 The external service must return a true/false response to confirm authentication.

Why Not the Other Options?

B. Delegated Auth is not for API/mobile apps (use OAuth instead).

C. Trusted IP ranges are not required at the Profile level (but may be needed for the auth service).

E. JIT provisioning is not part of Delegated Auth (it’s for SAML/OAuth).

Explanation:

High assurance sessions are sessions that require a stronger level of identity verification, such as two-factor authentication or SAML assertions1. Google Authenticator is an app that generates verification codes on your mobile device that you can use as a second factor of authentication2. These measures can help prevent unauthorized access to the connected app by ensuring that the user is who they claim to be and that they have access to their mobile device. Disallowing the use of single sign-on (SSO) for the mobile app is not a recommendation because SSO can provide a seamless and secure user experience across multiple applications3. Setting login IP ranges to the internal network for the app users profiles is not a recommendation because it can limit the mobility and flexibility of the users who are commonly out of the office.

Explanation:

Active Directory Password Sync Plugin allows users to log in to Salesforce with their Active Directory password without using a VPN. Salesforce Identity Connect synchronizes users and groups between Active Directory and Salesforce and enables single sign-on.

References: Active Directory Password Sync Plugin, Salesforce Identity Connect