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

Explanation:

The key constraints in this scenario are:

The authentication system must be Salesforce Identity (using Salesforce as the Identity Provider).
The target application is a custom B2C website.
The website does not support standard SSO protocols like SAML or OAuth.

Given these constraints, the solution must use an API-based authentication method that can be integrated into the custom website's code. The combination of a Connected App and Embedded Login provides this capability.

Why C (Connected Apps) is Correct:
A Connected App defines the application within Salesforce. It is a fundamental prerequisite for any external application that needs to authenticate using Salesforce. The Connected App is configured with OAuth policies (even though the website doesn't natively support OAuth, the authentication flow will use the OAuth 2.0 Resource Owner Password Credentials flow under the hood via the API). It acts as the trusted entity that grants access tokens.

Why D (Embedded Login) is Correct:
Embedded Login is a feature of Salesforce Identity that provides a set of tools (including a headless API and pre-built widgets) to embed the Salesforce login and registration experience directly into a custom web or mobile application. This is the specific tool designed for this exact use case: building a custom UI that authenticates against Salesforce without relying on the target application supporting standard SSO protocols. It handles the "username/password" authentication by communicating with Salesforce via API.

Why A (Identity Connect) is Incorrect:
Identity Connect is used to synchronize user accounts and passwords between Salesforce and an on-premises Active Directory. It is an identity synchronization tool, not an authentication mechanism for a custom website. It is irrelevant to this scenario.

Why B (Delegated Authentication) is Incorrect:
Delegated Authentication is a legacy feature where Salesforce delegates the authentication process to an external web service. In this scenario, NTO wants to use Salesforce Identity as the source of truth, not delegate to another system. Furthermore, Delegated Authentication is complex to implement, less secure, and not the recommended best practice. The modern, supported approach for a custom application to use Salesforce for authentication is via APIs and Embedded Login, not Delegated Authentication.

Reference:
Salesforce Help & Training: Embedded Login
This article explains that "Embedded Login lets you build a custom login experience for your external apps and communities using your own UI. Users can log in without leaving your site or being redirected to a Salesforce-hosted page."
Salesforce Help & Training: Create a Connected App
This is the foundational step for enabling API-based authentication for any external application.

Explanation:

When a company implements an SP-Initiated SAML flow with Salesforce, the user typically starts their login journey from a Salesforce-controlled URL (the Service Provider, or SP). For this to work correctly, the Salesforce login page needs to know to redirect the user to the external Identity Provider (IdP) for authentication.

The standard Salesforce login URL (login.salesforce.com) doesn't inherently know about a company's specific SSO configuration. However, a My Domain URL (e.g., uc.my.salesforce.com) is tied directly to the organization and its identity settings. When My Domain is enabled and configured, it provides a centralized and branded login page that can be set up to automatically redirect users to the IdP.

The Salesforce1 mobile app defaults to the standard login URL (login.salesforce.com). If a user attempts to log in for the first time without explicitly telling the app to use the company's My Domain, the app will present the standard Salesforce login screen, asking for a username and password. The user must manually tap the "Use Custom Domain" or similar option and enter the company's My Domain URL to initiate the correct SSO flow.
A. The "Redirect to Identity Provider" option has been selected in the my domain configuration. If this were the case, the flow would work as expected, and the user would be redirected to the IdP's login page, not the Salesforce login page.
C. The "Redirect to identity provider" option has not been selected the SAML configuration. The "Redirect to Identity Provider" setting is part of the My Domain setup, not the SAML configuration itself. The SAML configuration defines the trust relationship and assertion details, but the My Domain setting governs the login page behavior.
D. The user has not been granted the "Enable single Sign-on" permission. This permission is necessary for a user to be able to use SSO. If a user lacked this permission, they would likely receive a different error message, such as "Single Sign-On is not enabled for this user." The fact that they are prompted for Salesforce credentials suggests the system is simply defaulting to the standard login process, not denying them access based on a missing permission.

Explanation:

My Domain is essential for enabling Service Provider (SP)-initiated SAML SSO in Salesforce. It allows Salesforce to identify the correct org and redirect users to the appropriate Identity Provider (IdP) for authentication.

Without My Domain:
SP-initiated SSO fails because Salesforce cannot determine which SAML configuration to use when users start the login process from Salesforce.
IdP-initiated SSO still works because the login flow starts at the IdP, which sends a SAML assertion directly to Salesforce, bypassing the need for My Domain.

🔍 Why the other options are incorrect:
A. IdP-initiated SSO will NOT work Incorrect — IdP-initiated SSO does work without My Domain.
B. Neither SP- nor IdP-initiated SSO will work Incorrect — IdP-initiated SSO is still functional.
C. Either SP- or IdP-initiated SSO will work Incorrect — SP-initiated SSO requires My Domain.

📘 Reference:
Salesforce My Domain and SSO
SAML SSO Implementation Guide

Explanation:

Universal Containers (UC) has enabled refresh tokens for their mobile app to prevent users from re-entering credentials, but users still need to log in daily. Refresh tokens in Salesforce OAuth flows allow apps to obtain new access tokens without user re-authentication, typically lasting until revoked or expired. The issue likely stems from the refresh token configuration.

B. The refresh token expiration policy is set incorrectly in Salesforce:
This is the most likely cause. In Salesforce, the refresh token expiration policy for a Connected App can be configured to expire after a set period (e.g., 24 hours). If UC set the refresh token to expire daily, users would need to re-authenticate every 24 hours, causing the reported issue. Correcting the policy (e.g., setting it to "Refresh token is valid until revoked") would resolve this.

A. The OAuth authorizations are being revoked by a nightly batch job:
While possible, this is less likely without specific evidence of a batch job revoking tokens. Revocation typically occurs manually or through explicit admin action, not as a default behavior, and would likely cause immediate access issues, not a daily prompt.

C. The app is requesting too many access tokens in a 24-hour period:
Salesforce does limit access token issuance, but this would typically result in API errors (e.g., rate limit exceeded) rather than forcing daily re-authentication. Refresh tokens are designed to handle multiple access token requests, so this is unlikely.

D. The users forget to check the box to remember their credentials:
This is irrelevant in the context of OAuth refresh tokens, as the "remember credentials" option applies to browser-based login flows, not mobile apps using OAuth. The app should handle token refresh automatically.

Reference:
Salesforce Help: OAuth Tokens and Scopes
Salesforce Developer: Understanding Refresh Tokens

Explanation:

Universal Containers (UC) wants to ensure only active Salesforce users can access their proprietary order tracking system, which is only visible within Salesforce. To achieve this with SAML SSO in a secure and streamlined way, UC should:

A. Set up Salesforce as an Identity Provider (IdP) for Order Tracking.
By configuring Salesforce as an IdP, Salesforce becomes the trusted authority that issues SAML assertions about user identity. Since only active Salesforce user records can initiate a SAML assertion, this ensures that non-active users are automatically excluded.

D. Embed Order Tracking as a Canvas app in Salesforce and configure it to accept IdP-initiated SAML assertions.
A Canvas app runs inside Salesforce and seamlessly integrates with user context. When SAML assertions are sent (IdP-initiated POST), the Canvas app receives authenticated requests directly within the Salesforce session. This setup restricts access to only logged-in Salesforce users, aligning perfectly with the requirement that only active users can access the system.

Options B and C are invalid:
B points to using a corporate IdP external to Salesforce, which doesn't inherently enforce Salesforce user activity as a gating mechanism.
C involves custom REST calls to Salesforce after login, which adds complexity, maintenance burden, and potential security issues—whereas Canvas + IdP-initiated SSO is supported natively.

Explanation:

Universal Containers (UC) wants to limit user access to specific service providers (integrated via OpenID Connect as Connected Apps) based on customer type in their Customer Identity and Access Management solution. To achieve this, Salesforce provides mechanisms to control Connected App access through permissions and app settings.

C. Use Profiles and Permission Sets to assign user access to Admin Pre-Approved Connected Apps:
Correct. In Salesforce, access to Connected Apps can be restricted by setting the app to "Admin approved users are pre-authorized" and then assigning access via Profiles or Permission Sets. This allows UC to control which users (based on customer type) can access specific Connected Apps by assigning the appropriate Profile or Permission Set, ensuring granular access control.

D. Set each of the Connected App access settings to Admin Pre-Approved:
Correct. To enforce restricted access, each Connected App must be configured with the "Admin approved users are pre-authorized" setting in the Connected App configuration. This ensures that only users with the correct Profile or Permission Set (as set in option C) can access the app, aligning with UC’s requirement to limit access by customer type.

A. Manage which connected apps a user has access to by assigning authentication providers to the user’s profile: Incorrect. Authentication providers in Salesforce (e.g., for OpenID Connect) define the external IdP for SSO, not the specific Connected Apps a user can access. Assigning authentication providers to a profile doesn’t control Connected App access.

B. Assign the connected app to the customer community, and enable the users profile in the Community settings:
Incorrect. While Communities (now Experience Cloud) can be used to manage external user access, assigning a Connected App to a community and enabling profiles in Community settings doesn’t directly control access to specific Connected Apps. This approach is more about enabling community access, not restricting Connected App access by customer type.

References:
Salesforce Help: Manage Access to a Connected App
Salesforce Help: Connected App Access Control
Trailhead: Identity Basics - Connected Apps

Explanation:

To enable a single identity provider (IdP) to grant access to multiple Salesforce orgs, the key is to have a consistent, unique identifier that the IdP and each Salesforce org can agree on. That identifier is the Federation ID.

When a user attempts to log in via single sign-on (SSO), the IdP sends a SAML assertion to the Salesforce org. The SAML assertion contains a unique identifier for the user. Salesforce uses this value to find the corresponding user record in its database. The field Salesforce uses for this lookup is the Federation ID on the User object.

By ensuring that the same Federation ID value is populated for a single user across all of Universal Containers' Salesforce orgs, the IdP can send one consistent identifier, and each Salesforce org will be able to correctly match the incoming request to the right user record.

Why the other options are incorrect:
A. Ensure that users have the same email value in their user records in all of UC's salesforce orgs. While email is a unique identifier, Salesforce's SSO implementation uses the Federation ID as the primary key for matching a user from a SAML assertion. While you could set the Federation ID to the user's email address, simply having the same email in the user record isn't enough; the Federation ID field must be explicitly populated and configured for the SSO flow.
B. Ensure the same username is allowed in multiple orgs by contacting salesforce support. Salesforce usernames must be unique across all Salesforce orgs, not just within a single organization. Salesforce Support cannot change this fundamental rule. This is why a different identifier like the Federation ID is used for cross-org SSO.
D. Ensure that users have the same alias value in their user records in all of UC's salesforce orgs. An alias is a short, unique name used to identify a user in Chatter and other parts of the Salesforce UI. It is not used for authentication purposes and, like the username, must be unique within an org. It cannot be used to connect users across different orgs with a single IdP.

Explanation:

In this scenario, Universal Containers (UC) wants partners to log in through the corporate portal, which is managed by a third-party SAML Identity Provider (IdP). After logging in, partners will access Salesforce Partner Community resources via links from the portal.
This setup is best served by IdP-initiated SSO, where:

The login begins at the IdP (corporate portal).
The IdP sends a SAML assertion to Salesforce.
Users are seamlessly authenticated into Salesforce without needing to re-enter credentials.

This approach ensures a smooth, centralized login experience for partners and avoids the need for Salesforce to initiate the authentication flow.

❌ Why the other options are incorrect:
A. Connected App with Web Server OAuth flow
OAuth is typically used for API access or third-party app integrations, not for user login via SAML SSO.
B. SP-initiated SSO
This would require users to start the login process from Salesforce, which contradicts the scenario where login begins at the corporate portal.
C. Connected App with User Agent OAuth flow
Again, OAuth flows are not suitable for SAML-based login and are more relevant for mobile or browser-based apps accessing APIs.

📘 Reference:
Salesforce SAML SSO Overview
IdP-Initiated vs SP-Initiated SSO

Explanation:

Why:
In this scenario, employees don’t log in to Salesforce at all. They SSO into the legacy Employee portal (using SiteMinder + Active Directory). The portal then integrates with Salesforce Ideas via API (typically using an integration user / OAuth client credentials), which is not an SSO flow for end users. Since Salesforce isn’t participating in user authentication for employees, it isn’t acting as an SP or IdP here—it’s simply an external system being called by the portal. Hence, independent system is the correct role.

Why the others are not correct:
A (Service Provider): SP applies when users authenticate into Salesforce via SSO. They don’t.
B (Connected App): A Connected App can be used for OAuth/API access, but the question asks specifically about the SSO role; OAuth API auth ≠ SSO for end users.
C (Identity Provider): Salesforce isn’t issuing identities/tokens for users in this flow; AD/SiteMinder handle that.

Explanation:

Universal Containers (UC) wants to store user credentials in their custom employee hub application on AWS and enable these users to access Salesforce via authentication and authorization. The goal is to configure AWS to act as the identity provider (IdP) for Salesforce, allowing seamless SSO. Let’s evaluate the options:

B. Configure AWS as an OpenID Connect Provider: Correct.
AWS supports OpenID Connect (OIDC) through services like Amazon Cognito, which can be configured as an OIDC IdP. Salesforce supports OIDC for SSO, allowing AWS to authenticate users and provide identity assertions to Salesforce (acting as the Service Provider). This setup enables users to log in via AWS credentials and access Salesforce without separate authentication, meeting UC’s requirements.

A. Configure the custom employee app as a connected app: Incorrect.
A Connected App is a Salesforce configuration for integrating external applications with Salesforce, typically using OAuth or SAML. Configuring the AWS app as a Connected App would allow Salesforce users to access the AWS app, not the other way around (AWS authenticating Salesforce users).

C. Create a custom external authentication provider: Incorrect.
Salesforce’s external authentication provider framework is used for integrating with external IdPs via OpenID Connect or SAML. While AWS could be configured as an OIDC provider (as in option B), creating a custom authentication provider is unnecessary and overly complex, as AWS Cognito already supports OIDC natively.

D. Develop a custom Auth server in AWS: Incorrect.
Building a custom authentication server in AWS is possible but unnecessary, as AWS Cognito provides a robust, standards-based OIDC solution. This option adds complexity and maintenance overhead compared to using AWS’s existing OIDC capabilities.

Reference:
Salesforce Help: Set Up an OpenID Connect Provider
AWS Documentation: Amazon Cognito as OIDC Provider