You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -154,7 +154,7 @@ In the `ContosoCustomPolicy.XML` file, locate the *ClaimsTransformations* elemen
154
154
155
155
We've defined three Claims Transformations, which we use to generate values for *alternativeSecurityId* and *userPrincipalName* claims. These ClaimsTransformations are invoked in the OAuth2 Technical Profile in [step 3.3](#step-33---configure-facebook-claims-provider).
156
156
157
-
### Step 3.3 - Configure Facebook Claims Provider
157
+
### Step 3.3 - Configure Facebook claims provider
158
158
159
159
To enable users to sign in using a Facebook account, you need to define the account as a claims provider that Azure AD B2C can communicate with through an endpoint. You can define a Facebook account as a claims provider.
160
160
@@ -506,18 +506,12 @@ In this article, our user journey orchestration steps only references technical
506
506
507
507
Use the following steps to add a combined local and social account:
508
508
509
-
1.Declare a claim, `authenticationSource`, which specifies whether the user was authenticated at Social identity provider or a local account by using the following code:
509
+
1.In the `ContosoCustomPolicy.XML` file, locate the `AccountTypeInputCollector` self-asserted technical profile, and then add `authenticationSource` claim in its output claims collection by using the following code:
510
510
511
511
```xml
512
-
<!--<ClaimsSchema>-->
513
-
...
514
-
<ClaimTypeId="authenticationSource">
515
-
<DisplayName>AuthenticationSource</DisplayName>
516
-
<DataType>string</DataType>
517
-
<UserHelpText>Specifies whether the user was authenticated at Social IDP or local account.</UserHelpText>
In the fist step, we specify the options a user needs to choose from in their journey, local or social authentication. In the steps that follow, we use preconditions to track the option the user picked or the stage of the journey at which the user is. For example, we use the `authenticationSource` claim to differentiate between a local authentication journey and a social authentication journey.
678
+
679
+
1. In the `RelyingParty` section, change *DefaultUserJourney's* `ReferenceId` to `LocalAndSocialSignInAndSignUp`
680
+
681
+
1. Use the procedure in [step 6](#step-6---upload-policy) and [step 7](#step-7---test-policy) to upload and run your policy. After you run the policy, you'll see a screen similar to the following screenshot.
536
682
537
-
1. Upload policy file
683
+
:::image type="content" source="media/custom-policies-series-sign-up-or-sign-in-federation/screenshot-combined-local-and-social-sign-up-or-sign-in.png" alt-text="A screenshot combined local and social sign up or sign in interface.":::
538
684
539
-
1. Run policy (include screenshot)
685
+
You can observe that a user can sign up or sign in by using either a local account or a social account.
0 commit comments