markdig migration for 2019-03-15

Author: daxianji007

articles/active-directory-b2c/active-directory-b2c-create-custom-attributes-profile-edit-custom.md

@@ -255,20 +255,20 @@ The ID token sent back to your application includes the new extension property a
 
 1. Add the new claim to the flows to sign in to social accounts by changing the following **TechnicalProfiles**. Social and federated accounts use these two **TechnicalProfiles** to sign in. They write and read user data by using the **alternativeSecurityId** as the locator of the user object.
 
-  ```xml
+   ```xml
     <TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
 
     <TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">
-  ```
+   ```
 
 2. Use the same extension attributes between built-in and custom policies. When you add extension, or custom, attributes via the portal experience, those attributes are registered by using the **b2c-extensions-app** that exists in every B2C tenant. Take the following steps to use extension attributes in your custom policy:
 
-  a. Within your B2C tenant in portal.azure.com, navigate to **Azure Active Directory** and select **App registrations**.  
-  b. Find your **b2c-extensions-app** and select it.  
-  c. Under **Essentials**, enter the **Application ID** and the **Object ID**.  
-  d. Include them in your **AAD-Common** TechnicalProfile metadata:  
+   a. Within your B2C tenant in portal.azure.com, navigate to **Azure Active Directory** and select **App registrations**.  
+   b. Find your **b2c-extensions-app** and select it.  
+   c. Under **Essentials**, enter the **Application ID** and the **Object ID**.  
+   d. Include them in your **AAD-Common** TechnicalProfile metadata:  
 
-  ```xml
+   ```xml
       <ClaimsProviders>
         <ClaimsProvider>
           <DisplayName>Azure Active Directory</DisplayName>
@@ -280,14 +280,14 @@ The ID token sent back to your application includes the new extension property a
               <Item Key="ApplicationObjectId">insert objectId here</Item> <!-- This is the "Object ID" from the "b2c-extensions-app"-->
               <Item Key="ClientId">insert appId here</Item> <!--This is the "Application ID" from the "b2c-extensions-app"-->
             </Metadata>
-  ```
+   ```
 
 3. Stay consistent with the portal experience. Create these attributes by using the portal UI before you use them in your custom policies. When you create an attribute **ActivationStatus** in the portal, you must refer to it as follows:
 
-  ```
-  extension_ActivationStatus in the custom policy.
-  extension_<app-guid>_ActivationStatus via Graph API.
-  ```
+   ```
+   extension_ActivationStatus in the custom policy.
+   extension_<app-guid>_ActivationStatus via Graph API.
+   ```
 
 ## Reference
 

articles/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw.md

@@ -245,10 +245,10 @@ A claims provider can have multiple technical profiles for various reasons. For
 The following XML snippet contains a claims provider node with two technical profiles:
 
 * **TechnicalProfile Id="REST-API-SignUp"**: Defines your RESTful service.
-   * `Proprietary` is described as the protocol for a RESTful-based provider.
-   * `InputClaims` defines the claims that will be sent from Azure AD B2C to the REST service.
+  * `Proprietary` is described as the protocol for a RESTful-based provider.
+  * `InputClaims` defines the claims that will be sent from Azure AD B2C to the REST service.
 
-   In this example, the content of the claim `givenName` sends to the REST service as `firstName`, the content of the claim `surname` sends to the REST service as `lastName`, and `email` sends as is. The `OutputClaims` element defines the claims that are retrieved from RESTful service back to Azure AD B2C.
+    In this example, the content of the claim `givenName` sends to the REST service as `firstName`, the content of the claim `surname` sends to the REST service as `lastName`, and `email` sends as is. The `OutputClaims` element defines the claims that are retrieved from RESTful service back to Azure AD B2C.
 
 * **TechnicalProfile Id="LocalAccountSignUpWithLogonEmail"**: Adds a validation technical profile to an existing technical profile (defined in base policy). During the sign-up journey, the validation technical profile invokes the preceding technical profile. If the RESTful service returns an HTTP error 409 (a conflict error), the error message is displayed to the user.
 

articles/active-directory-b2c/active-directory-b2c-reference-customize-ui-custom.md

@@ -118,16 +118,16 @@ To verify that the storage you are hosting your content on has CORS enabled, pro
 
 1. Open a browsing session and navigate to the page *unified.html* using the full URL of its location in your storage account, `https://<storageAccountName>.blob.core.windows.net/<containerName>/unified.html`. For example, https://contoso369b2c.blob.core.windows.net/b2c/unified.html.
 2. Navigate to https://test-cors.org. This site allows you to verify that the page you are using has CORS enabled.  
-<!--
-![test-cors.org](../../media/active-directory-b2c-customize-ui-of-a-user-journey/test-cors.png)
--->
+   <!--
+   ![test-cors.org](../../media/active-directory-b2c-customize-ui-of-a-user-journey/test-cors.png)
+   -->
 
 3. In **Remote URL**, enter the full URL for your unified.html content, and click **Send Request**.
 4. Verify that the output in the **Results** section contains *XHR status: 200*, which indicates that CORS is enabled.
-<!--
-![CORS enabled](../../media/active-directory-b2c-customize-ui-of-a-user-journey/cors-enabled.png)
--->
-The storage account should now contain a blob container named *b2c* in the illustration that contains the following wingtiptoys templates from the *Starter-Pack*.
+   <!--
+   ![CORS enabled](../../media/active-directory-b2c-customize-ui-of-a-user-journey/cors-enabled.png)
+   -->
+   The storage account should now contain a blob container named *b2c* in the illustration that contains the following wingtiptoys templates from the *Starter-Pack*.
 
 <!--
 ![Correctly configured storage account](../../articles/active-directory-b2c/media/active-directory-b2c-reference-customize-ui-custom/storage-account-final.png)

articles/active-directory-b2c/active-directory-b2c-social-migration.md

@@ -28,14 +28,14 @@ This article is a continuation of the user migration article, and focuses on soc
 * **Combine local account with social identity**. As mentioned, local account sign-in names, and social account identities are stored in different attributes. `signInNames` is used for local account, while `userIdentities` for social account. A single Azure AD B2C account, can be a local account only, social account only, or combine a local account with social identity in one user record. This behavior allows you to manage a single account, while a user can sign in with the local account credential(s) or with the social identities.
 
 * `UserIdentity` Type - Contains information about the identity of a social account user in an Azure AD B2C tenant:
-    * `issuer` The string representation of the identity provider that issued the user identifier, such as facebook.com.
-    * `issuerUserId` The unique user identifier used by the social identity provider in base64 format.
+  * `issuer` The string representation of the identity provider that issued the user identifier, such as facebook.com.
+  * `issuerUserId` The unique user identifier used by the social identity provider in base64 format.
 
     ```JSON
     "userIdentities": [{
-            "issuer": "Facebook.com",
-            "issuerUserId": "MTIzNDU2Nzg5MA=="
-        }
+          "issuer": "Facebook.com",
+          "issuerUserId": "MTIzNDU2Nzg5MA=="
+      }
     ]
     ```
 

articles/active-directory-b2c/active-directory-b2c-troubleshoot-custom.md

@@ -40,40 +40,40 @@ Azure AD B2C supports a feature for sending data to Application Insights.  Appli
 1. Open the RP file (for example, SignUpOrSignin.xml).
 1. Add the following attributes to the `<TrustFrameworkPolicy>` element:
 
-  ```XML
-  DeploymentMode="Development"
-  UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights"
-  ```
+   ```XML
+   DeploymentMode="Development"
+   UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights"
+   ```
 
 1. If it doesn't exist already, add a child node `<UserJourneyBehaviors>` to the `<RelyingParty>` node. It must be located immediately after the `<DefaultUserJourney ReferenceId="UserJourney Id from your extensions policy, or equivalent (for example:SignUpOrSigninWithAAD" />`
 2. Add the following node as a child of the `<UserJourneyBehaviors>` element. Make sure to replace `{Your Application Insights Key}` with the **Instrumentation Key** that you obtained from Application Insights in the previous section.
 
-  ```XML
-  <JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="{Your Application Insights Key}" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
-  ```
+   ```XML
+   <JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="{Your Application Insights Key}" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
+   ```
 
-  * `DeveloperMode="true"` tells ApplicationInsights to expedite the telemetry through the processing pipeline, good for development, but constrained at high volumes.
-  * `ClientEnabled="true"` sends the ApplicationInsights client-side script for tracking page view and client-side errors (not needed).
-  * `ServerEnabled="true"` sends the existing UserJourneyRecorder JSON as a custom event to Application Insights.
-Sample:
+   * `DeveloperMode="true"` tells ApplicationInsights to expedite the telemetry through the processing pipeline, good for development, but constrained at high volumes.
+   * `ClientEnabled="true"` sends the ApplicationInsights client-side script for tracking page view and client-side errors (not needed).
+   * `ServerEnabled="true"` sends the existing UserJourneyRecorder JSON as a custom event to Application Insights.
+   Sample:
 
-  ```XML
-  <TrustFrameworkPolicy
+   ```XML
+   <TrustFrameworkPolicy
     ...
     TenantId="fabrikamb2c.onmicrosoft.com"
     PolicyId="SignUpOrSignInWithAAD"
     DeploymentMode="Development"
     UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights"
-  >
+   >
     ...
     <RelyingParty>
       <DefaultUserJourney ReferenceId="UserJourney ID from your extensions policy, or equivalent (for example: SignUpOrSigninWithAzureAD)" />
       <UserJourneyBehaviors>
         <JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="{Your Application Insights Key}" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
       </UserJourneyBehaviors>
       ...
-  </TrustFrameworkPolicy>
-  ```
+   </TrustFrameworkPolicy>
+   ```
 
 3. Upload the policy.
 

articles/active-directory-b2c/configure-ropc.md

@@ -33,15 +33,15 @@ The following flows are not supported:
 
 ##  Create a resource owner user flow
 
-1.	Sign in to the Azure portal as the global administrator of your Azure AD B2C tenant.
-2.	To switch to your Azure AD B2C tenant, select the B2C directory in the upper-right corner of the portal.
-3.	Click **User flows**, and select **New user flow**.
-4.	Click the **All** tab and select **Sign in using ROPC**.
-5.	Provide a name for the user flow, such as *ROPC_Auth*.
-6.	Under **Application claims**, click **Show more**.
-7.	Select the application claims that you need for your application, such as Display Name, Email Address, and Identity Provider.
-8.	Select **OK**, and then select **Create**.
-9.	Click **Run user flow**.
+1. Sign in to the Azure portal as the global administrator of your Azure AD B2C tenant.
+2. To switch to your Azure AD B2C tenant, select the B2C directory in the upper-right corner of the portal.
+3. Click **User flows**, and select **New user flow**.
+4. Click the **All** tab and select **Sign in using ROPC**.
+5. Provide a name for the user flow, such as *ROPC_Auth*.
+6. Under **Application claims**, click **Show more**.
+7. Select the application claims that you need for your application, such as Display Name, Email Address, and Identity Provider.
+8. Select **OK**, and then select **Create**.
+9. Click **Run user flow**.
 
    You'll then see an endpoint such as this example:
 

articles/active-directory-b2c/general-transformations.md

@@ -44,7 +44,7 @@ Use this claims transformation to check if a claim exists or contains any value.
 ### Example
 
 - Input claims:
-    - **inputClaim**: someone@contoso.com
+  - **inputClaim**: someone@contoso.com
 - Output claims: 
     - **outputClaim**: true
 

articles/active-directory-b2c/json-transformations.md

@@ -48,11 +48,11 @@ In the following example, the claims transformation extracted the `emailAddress`
 ### Example
 
 - Input claims:
-    - **inputJson**: {"emailAddress": "someone@example.com", "displayName": "Someone"}
+  - **inputJson**: {"emailAddress": "someone@example.com", "displayName": "Someone"}
 - Input parameter:
     - **claimToExtract**: emailAddress
 - Output claims: 
-    - **extractedClaim**: someone@example.com
+  - **extractedClaim**: someone@example.com
 
 
 ## GetClaimsFromJsonArray
@@ -96,18 +96,18 @@ In the following example, the claims transformation extracts the following claim
 ```    
 
 - Input claims:
-    - **jsonSourceClaim**: [{"key":"email","value":"someone@example.com"}, {"key":"displayName","value":"Someone"}, {"key":"membershipNum","value":6353399}, {"key":"active","value": true}, {"key":"birthdate","value":"1980-09-23T00:00:00Z"}]
+  - **jsonSourceClaim**: [{"key":"email","value":"someone@example.com"}, {"key":"displayName","value":"Someone"}, {"key":"membershipNum","value":6353399}, {"key":"active","value": true}, {"key":"birthdate","value":"1980-09-23T00:00:00Z"}]
 - Input parameters:
     - **errorOnMissingClaims**: false
     - **includeEmptyClaims**: false
     - **jsonSourceKeyName**: key
     - **jsonSourceValueName**: value
 - Output claims:
-    - **email**: "someone@example.com"
-    - **displayName**: "Someone"
-    - **membershipNum**: 6353399
-    - **active**: true
-    - **birthdate**: 1980-09-23T00:00:00Z
+  - **email**: "someone@example.com"
+  - **displayName**: "Someone"
+  - **membershipNum**: 6353399
+  - **active**: true
+  - **birthdate**: 1980-09-23T00:00:00Z
 
 ## GetNumericClaimFromJson
 
@@ -146,7 +146,7 @@ In the following example, the claims transformation extracts the `id` element fr
 ### Example
 
 - Input claims:
-    - **inputJson**: {"emailAddress": "someone@example.com", "displayName": "Someone", "id" : 6353399}
+  - **inputJson**: {"emailAddress": "someone@example.com", "displayName": "Someone", "id" : 6353399}
 - Input parameters
     - **claimToExtract**:  id
 - Output claims: 
@@ -177,9 +177,9 @@ In the following example, the claims transformation extracts the first element (
 ### Example
 
 - Input claims:
-    - **inputJsonClaim**: ["someone@example.com", "Someone", 6353399]
+  - **inputJsonClaim**: ["someone@example.com", "Someone", 6353399]
 - Output claims: 
-    - **extractedClaim**: someone@example.com
+  - **extractedClaim**: someone@example.com
 
 ## XmlStringToJsonString
 

articles/active-directory-b2c/restful-technical-profile.md

@@ -168,13 +168,13 @@ The following example shows a REST API that returns an error message formatted i
 
 ```JSON
 {
-  "version": "1.0.0",
-  "status": 409,
-  "code": "API12345",
-  "requestId": "50f0bd91-2ff4-4b8f-828f-00f170519ddb",
-  "userMessage": "Message for the user", 
-  "developerMessage": "Verbose description of problem and how to fix it.", 
-  "moreInfo": "https://restapi/error/API12345/moreinfo" 
+  "version": "1.0.0",
+  "status": 409,
+  "code": "API12345",
+  "requestId": "50f0bd91-2ff4-4b8f-828f-00f170519ddb",
+  "userMessage": "Message for the user", 
+  "developerMessage": "Verbose description of problem and how to fix it.", 
+  "moreInfo": "https://restapi/error/API12345/moreinfo" 
 }
 ```
 

articles/active-directory-b2c/string-transformations.md

@@ -74,10 +74,10 @@ The self-asserted technical profile calls the validation **login-NonInteractive*
 ### Example
 
 - Input claims:
-    - **inputClaim1**: someone@contoso.com
-    - **inputClaim2**: someone@outlook.com
- - Input parameters:
-    - **stringComparison**:  ordinalIgnoreCase
+  - **inputClaim1**: someone@contoso.com
+  - **inputClaim2**: someone@outlook.com
+    - Input parameters:
+  - **stringComparison**:  ordinalIgnoreCase
 - Result: Error thrown
 
 ## ChangeCase 
@@ -109,11 +109,11 @@ Use this claim transformation to change any string ClaimType to lower or upper c
 ### Example
 
 - Input claims:
-    - **email**: SomeOne@contoso.com
+  - **email**: SomeOne@contoso.com
 - Input parameters:
     - **toCase**: LOWER
 - Output claims:
-    - **email**: someone@contoso.com
+  - **email**: someone@contoso.com
 
 ## CreateStringClaim 
 
@@ -177,8 +177,8 @@ Use this claims transformation to check if a claim is equal to another claim. Fo
 ### Example
 
 - Input claims:
-    - **inputClaim1**: someone@contoso.com
-    - **inputClaim2**: someone@outlook.com
+  - **inputClaim1**: someone@contoso.com
+  - **inputClaim2**: someone@outlook.com
 - Input parameters:
     - **operator**:  NOT EQUAL
     - **ignoreCase**: true
@@ -317,7 +317,7 @@ Use this claims transformation to format any string with one parameter {0}. The
 - Input parameters:
     - **stringFormat**:  cpim_{0}@{RelyingPartyTenantId}
 - Output claims:
-    - **outputClaim**: cpim_5164db16-3eee-4629-bfda-dcc3326790e9@b2cdemo.onmicrosoft.com
+  - **outputClaim**: cpim_5164db16-3eee-4629-bfda-dcc3326790e9@b2cdemo.onmicrosoft.com
 
 ## FormatStringMultipleClaims
 
@@ -490,7 +490,7 @@ Use this claims transformation to parse the domain name after the @ symbol of th
 ### Example
 
 - Input claims:
-    - **emailAddress**: joe@outlook.com
+  - **emailAddress**: joe@outlook.com
 - Output claims:
     - **domain**: outlook.com