Merge branch 'main' into patch-1

Author: v-dirichards

.github/workflows/stale.yml

@@ -128,12 +128,6 @@
             "branch": "master",
             "branch_mapping": {}
         },
-        {
-            "path_to_root": "azure-docs-snippets-pr",
-            "url": "https://github.com/MicrosoftDocs/azure-docs-snippets-pr",
-            "branch": "main",
-            "branch_mapping": {}
-        },
         {
             "path_to_root": "azure-functions-dapr-extension",
             "url": "https://github.com/Azure/azure-functions-dapr-extension",

.openpublishing.publish.config.json

@@ -118,6 +118,21 @@ You need more claims to enable CAPTCHA in your custom policy:
         <DisplayName>Flag indicating that the captcha was successfully solved</DisplayName>
         <DataType>boolean</DataType>
       </ClaimType>
+
+      <ClaimType Id="mfaCaptchaEnabled">
+        <DisplayName>flag used to control captcha enabled in MFA</DisplayName>
+        <DataType>string</DataType>
+      </ClaimType>
+
+      <ClaimType Id="signupCaptchaEnabled">
+        <DisplayName>flag used to control captcha enabled during signup</DisplayName>
+        <DataType>string</DataType>
+      </ClaimType>
+
+      <ClaimType Id="signinCaptchaEnabled">
+        <DisplayName>flag used to control captcha enabled during signin</DisplayName>
+        <DataType>string</DataType>
+      </ClaimType>
       ...
      <!--<ClaimsSchema>-->
     ``` 
@@ -314,6 +329,58 @@ To enable CAPTCHA in MFA flow, you need to make an update in two technical profi
     ...
 </TechnicalProfile>
 ```
+
+### Enable CAPTCHA feature flag
+
+To enforce CAPTCHA during sign-up, sign-in, or MFA, you need to add a technical profile that enables a feature flag for each scenario, then call the technical profile in the user journey.
+
+1. In the *TrustFrameworkBase.XML* file, locate the `ClaimsProviders` element and add the claims provider by using the following code:
+
+```xml
+<!--<ClaimsProvider>-->
+...
+<ClaimsProvider>
+
+    <DisplayName>Set Feature Flags</DisplayName>
+
+    <TechnicalProfiles>
+
+    <TechnicalProfile Id="SetFeatureDefaultValue">
+        <DisplayName>Set Feature Flags</DisplayName>
+        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
+        <OutputClaims>
+            <OutputClaim ClaimTypeReferenceId="signupCaptchaEnabled" DefaultValue="true" />
+            <OutputClaim ClaimTypeReferenceId="signinCaptchaEnabled" DefaultValue="true" />
+            <OutputClaim ClaimTypeReferenceId="mfaCaptchaEnabled" DefaultValue="true" />
+        </OutputClaims>
+    </TechnicalProfile>
+    </TechnicalProfiles>
+</ClaimsProvider>
+...
+<!--<ClaimsProviders>-->
+``` 
+
+2. Set `DefaultValue` to true or false depending on the CAPTCHA scenario
+
+3. Add the feature flags technical profile to the user journey then update the order of the rest of the orchestration steps.
+
+```xml
+<!--<UserJourneys>-->
+...
+<UserJourney Id="SignUpOrSignIn">
+    <OrchestrationSteps>
+
+        <!--Add this orchestration step-->
+        <OrchestrationStep Order="1" Type="ClaimsExchange">
+          <ClaimsExchanges>
+            <ClaimsExchange Id="SetFeatureDefaultValue" TechnicalProfileReferenceId="SetFeatureDefaultValue" />
+          </ClaimsExchanges>
+        </OrchestrationStep>
+...
+<!--<UserJourneys>-->
+```
+
+
 ## Upload the custom policy files
 
 Use the steps in [Upload the policies](tutorial-create-user-flows.md?pivots=b2c-custom-policy&branch=pr-en-us-260336#upload-the-policies) to upload your custom policy files.

.openpublishing.redirection.json

@@ -244,7 +244,7 @@ If you reference a REST API technical profile directly from a user journey, the
 
 ## Development of your REST API 
 
-Your REST API can be developed on any platform and written in any programing language, as long as it's secure and can send and receive claims in JSON format.
+Your REST API can be developed on any platform and written in any programming language, as long as it's secure and can send and receive claims in JSON format.
 
 The request to your REST API service comes from Azure AD B2C servers. The REST API service must be published to a publicly accessible HTTPS endpoint. The REST API call arrives from an Azure data center IP address.
 

articles/active-directory-b2c/add-captcha.md

@@ -325,7 +325,7 @@ The **DateTimeDropdown** user input type is used to provide a set of drop-downs
 
 The **RadioSingleSelect** user input type is used to provide a collection of radio buttons that allows the user to select one option.
 
-![Using claim type with radiodsingleselect](./media/claimsschema/radiosingleselect.png)
+![Using claim type with radiosingleselect](./media/claimsschema/radiosingleselect.png)
 
 ```xml
 <ClaimType Id="color">

articles/active-directory-b2c/api-connectors-overview.md

@@ -190,7 +190,7 @@ Your final configuration file should look like the following JSON:
 ```json
 {
     "credentials": {
-        "tenantName": "<your-tenant-namee>",
+        "tenantName": "<your-tenant-name>",
         "clientID": "<your-webapi-application-ID>",
         "issuer": "https://<your-tenant-name>.b2clogin.com/<your-tenant-ID>/v2.0/"
     },

articles/active-directory-b2c/claimsschema.md

@@ -41,7 +41,7 @@ In the [Azure AD B2C samples GitHub repository](https://github.com/azure-ad-b2c/
 
 ### Claims
 
-A claim provides temporary storage of data during an Azure AD B2C policy execution. Claims are more like variable in a programing language. It can store information about the user, such as first name, last name, or any other claim obtained from the user or other systems (claims exchanges). The [claims schema](claimsschema.md) is the place where you declare your claims. 
+A claim provides temporary storage of data during an Azure AD B2C policy execution. Claims are more like variable in a programming language. It can store information about the user, such as first name, last name, or any other claim obtained from the user or other systems (claims exchanges). The [claims schema](claimsschema.md) is the place where you declare your claims. 
 
 When the policy runs, Azure AD B2C sends and receives claims to and from internal and external parties and then sends a subset of these claims to your relying party application as part of the token. Claims are used in these ways: 
 

articles/active-directory-b2c/configure-authentication-sample-angular-spa-app.md

@@ -71,7 +71,7 @@ To use a session provider in your technical profile:
 
     ```xml
     <TechnicalProfile Id="SM-AAD">
-      <DisplayName>Session Mananagement Provider</DisplayName>
+      <DisplayName>Session Management Provider</DisplayName>
       <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
       <PersistedClaims>
         <PersistedClaim ClaimTypeReferenceId="objectId" />

articles/active-directory-b2c/custom-policy-overview.md

@@ -411,7 +411,7 @@ if (this.msalGuardConfig.authRequest) {
   authRequestConfig = { ...this.msalGuardConfig.authRequest } as RedirectRequest
 }
 
-authRequestConfig.extraQueryParameters = {"id_token_hint": idToken};;
+authRequestConfig.extraQueryParameters = {"id_token_hint": idToken};
 
 this.authService.loginRedirect(authRequestConfig);