Containers (UC) has decided to implement a federated single Sign-on solution using a third-party Idp. In reviewing the third-party products, they would like to ensure the product supports the automated provisioning and deprovisioning of users. What are the underlining mechanisms that the UC Architect must ensure are part of the product?

1. A. SOAP API for provisioning; Just-in-Time (JIT) for Deprovisioning.
2. B. Just-In-time (JIT) for Provisioning; SOAP API for Deprovisioning.
3. C. Provisioning API for both Provisioning and Deprovisioning.
4. D. Just-in-Time (JIT) for both Provisioning and Deprovisionin

Correct Answer: D
Just-in-Time (JIT) provisioning and deprovisioning can be used to create, update, or deactivate users in Salesforce based on the information in the SAML assertion sent by the IdP. This way, the user lifecycle can be managed automatically without the need for a separate provisioning API. Reference: [Salesforce Help:
Just-in-Time Provisioning for SAML]

Universal Containers (UC) is rolling out its new Customer Identity and Access Management Solution built on top of its existing Salesforce instance. UC wants to allow customers to login using Facebook, Google, and other social sign-on providers.
How should this functionality be enabled for UC, assuming ail social sign-on providers support OpenID Connect?

1. A. Configure an authentication provider and a registration handler for each social sign-on provider.
2. B. Configure a single sign-on setting and a registration handler for each social sign-on provider.
3. C. Configure an authentication provider and a Just-In-Time (JIT) handler for each social sign-on provider.
4. D. Configure a single sign-on setting and a JIT handler for each social sign-on provider.

Correct Answer: A
To allow customers to login using Facebook, Google, and other social sign-on providers, the identity architect should configure an authentication provider and a registration handler for each social sign-on provider. Authentication providers are configurations that enable users to authenticate with an external identity provider and access Salesforce resources. OpenID Connect is a protocol that allows users to sign in with an external identity provider, such as Facebook or Google, and access Salesforce resources. To enable this, the identity architect needs to configure an OpenID Connect Authentication Provider in Salesforce and link it to a connected app. A registration handler is a class that implements the Auth.RegistrationHandler interface and defines how to create or update users in Salesforce based on the information from the external identity provider. The registration handler can also be used to link the user’s social identity with their Salesforce identity and prevent duplicate accounts. References: OpenID Connect Authentication Providers, Social Sign-On with OpenID Connect, Create a Custom Registration Handler

Northern Trail Outfitters (NTO) has a number of employees who do NOT need access Salesforce objects. Trie employees should sign in to a custom Benefits web app using their Salesforce credentials.
Which license should the identity architect recommend to fulfill this requirement?

1. A. Identity Only License
2. B. External Identity License
3. C. Identity Verification Credits Add-on License
4. D. Identity Connect License

Correct Answer: A
To allow employees to sign in to a custom Benefits web app using their Salesforce credentials, the identity architect should recommend the Identity Only License. The Identity Only License is a license type that enables users to access external applications that are integrated with Salesforce using single sign-on (SSO) or delegated authentication, but not access Salesforce objects or data. The other license types are not relevant for this scenario. References: Identity Only License, User Licenses

Universal containers wants salesforce inbound Oauth-enabled integration clients to use SAML-BASED single Sign-on for authentication. What Oauth flow would be recommended in this scenario?

1. A. User-Agent Oauth flow
2. B. SAML assertion Oauth flow
3. C. User-Token Oauth flow
4. D. Web server Oauth flow

Correct Answer: B
The SAML assertion OAuth flow allows a connected app to use a SAML assertion to request an OAuth access token to call Salesforce APIs. This flow provides an alternative for orgs that are currently using SAML to access Salesforce and want to access the web services API in the same way3. This flow can be used for inbound OAuth-enabled integration clients that want to use SAML-based single sign-on for authentication.
References: OAuth 2.0 SAML Bearer Assertion Flow for Previously Authorized Apps, Access Data with AP
Integration, Error ‘Invalid assertion’ in OAuth 2.0 SAML Bearer Flow

Universal Containers (UC) implemented SSO to a third-party system for their Salesforce users to access the App Launcher. UC enabled “User Provisioning” on the Connected App so that changes to user accounts can be synched between Salesforce and the third-party system. However, UC quickly notices that changes to user roles in Salesforce are not getting synched to the third-party system. What is the most likely reason for this behavior?

1. A. User Provisioning for Connected Apps does not support role sync.
2. B. Required operation(s) was not mapped in User Provisioning Settings.
3. C. The Approval queue for User Provisioning Requests is unmonitored.
4. D. Salesforce roles have more than three levels in the role hierarchy.

Correct Answer: B
User Provisioning for Connected Apps supports role sync, but the required operation(s) must be mapped in User Provisioning Settings. According to the Salesforce documentation1, “To provision roles, map the Role operation to a field in the connected app. The field must contain the role’s unique name.” Therefore, option B is the correct answer.
References: Salesforce Documentation