Master the Salesforce Certified Identity and Access Management Architect (WI24) Identity-and-Access-Management-Architect Exam with Confidence!

 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

The web service that is used for delegated authentication should be secured with TLS using Salesforce trusted certificates4. This ensures that the communication between Salesforce and the external authentication method is encrypted and authenticated. The other options are not relevant for designing a delegated authentication implementation. The web service does not need to accept one to four input method parameters, as it can accept any number of parameters as long as they are wrapped in a SOAP envelope5. The web service does not need to use the Salesforce Federation ID to identify the user, as it can use any identifier that is unique and consistent across systems6. The web service does not need to implement a custom password decryption method, as it can use any encryption or hashing algorithm that is supported by both systems7. References: Delegated Authentication, Enable ‘Delegated Authentication’, Delegated Authentication Flow in Salesforce, FAQs for Delegated Authentication

To prevent unauthorized form submissions during the self-registration process, UC should require a captcha at the end of the self-registration process and use hidden fields populated via JavaScript events in the self-registration page. These methods will help to verify that the user is a human and not a bot, and also to validate the user’s input against some predefined values. Option A is not a good choice because open-ended security questions and complex password requirements may frustrate the user and reduce the conversion rate. Option B is not a good choice because lookup and picklist fields may not prevent bots from submitting the form, as they can be easily automated or bypassed.

References: Single Sign-On Implementation Guide, Customizing User Authentication with Login Flows

Two-way SSL is a method of mutual authentication between two parties using digital certificates. A digital certificate is an electronic document that contains information about the identity of the certificate owner and a public key that can be used to verify their signature. A digital certificate can be either self-signed or CA-signed. A self-signed certificate is created and signed by its owner, while a CA-signed certificate is created by its owner but signed by a trusted Certificate Authority (CA). For setting up two-way SSL between Salesforce and an external system, two valid choices for digital certificates are:

• Use a self-signed certificate for Salesforce and a self-signed certificate for the external system. This option is simple and cost-effective, but requires both parties to trust each other’s self-signed certificates explicitly.
• Use a self-signed certificate for Salesforce and a trusted CA-signed certificate for the external system. This option is more secure and reliable, but requires Salesforce to trust the CA that signed the external system’s certificate implicitly.

References: Know more about all the SSL certificates that are supported by Salesforce, two way ssl. How to?

To track login data, such as the average number of logins, who logged in more than the average number of times and who logged in during non-business hours, the identity architect should use Login Forensics. Login Forensics is a tool that analyzes login data and provides insights into user behavior and login patterns. Login Forensics can help identify anomalies, risks, and trends in user login activity. Login Forensics can also generate reports and dashboards to visualize the login data. References: Login Forensics, Analyze Login Data with Login Forensics

D is correct because using custom login flows with callouts to a third-party fingerprint scanning application allows UC to support fingerprints as a form of identification for Salesforce authentication. Custom login flows allow UC to implement custom logic and UI elements for authentication, such as calling an external web service that performs fingerprint scanning and verification. A is incorrect because using Salesforce two-factor authentication with callouts to a third-party fingerprint scanning application does not support fingerprints as a form of identification for Salesforce authentication. Salesforce two-factor authentication requires users to enter a verification code or use an app like Salesforce Authenticator, not a fingerprint. B is incorrect because using delegated authentication with callouts to a third-party fingerprint scanning application does not support fingerprints as a form of identification for Salesforce authentication. Delegated authentication requires users to enter their username and password, not a fingerprint. C is incorrect because using an AppExchange product that does fingerprint scanning with native Salesforce identity confirmation does not support fingerprints as a form of identification for Salesforce authentication. AppExchange products are third-party applications that integrate with Salesforce, not native Salesforce features. Verified References: [Custom Login Flows], [Two-Factor Authentication], [Delegated Authentication], [AppExchange]

 Identity Connect is a Salesforce product that integrates Microsoft Active Directory with Salesforce user records. It allows provisioning, deprovisioning, and authentication of users based on AD data. The other options are either incorrect or irrelevant for this use case. References: Get to Know Identity Connect, Identity Connect

External Identity Licenses are required to enable external users to access Salesforce resources via a CIAM solution. Email Verification Credits and SMS Verification Credits are required to enable email or mobile phone number verification for user authentication. Identity Connect Licenses are not required for this scenario, as Identity Connect is a tool for synchronizing user data between Salesforce and Active Directory. References: External Identity Implementation Guide, Identity Connect Implementation Guide

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.

References:

• OAuth 2.0 Device Flow

Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials4. There are two types of SSO flows that can be used with Salesforce as the service provider (SP) and an external identity provider (IdP)5:

• Service-provider-initiated SSO: The user requests a resource from the SP, such as a Salesforce URL. The SP redirects the user to the IdP for authentication. The IdP authenticates the user and sends a SAML response to the SP. The SP validates the SAML response and grants access to the user5. This type of SSO flow supports deep linking, which means that the user can access a specific page within Salesforce without logging in again6.
• Identity-provider-initiated SSO: The user logs in to the IdP and selects an app from a list of available apps. The IdP sends a SAML response to the SP. The SP validates the SAML response and grants access to the user5. This type of SSO flow does not support deep linking, which means that the user can only access the default landing page of Salesforce6.

References:

• Single Sign-On
• SAML SSO Flows
• Deep Linking