Merge pull request #302223 from MicrosoftDocs/main

Merged by Learn.Build PR Management system

Author: learn-build-service-prod[bot]

articles/active-directory-b2c/whats-new-docs.md

@@ -1,7 +1,7 @@
 ---
 title: "What's new in Azure Active Directory business-to-customer (B2C)"
 description: "New and updated documentation for the Azure Active Directory business-to-customer (B2C)."
-ms.date: 04/01/2025
+ms.date: 07/03/2025
 ms.service: azure-active-directory
 ms.subservice: b2c
 ms.topic: whats-new
@@ -18,6 +18,15 @@ manager: CelesteDG
 
 Welcome to what's new in Azure Active Directory B2C documentation. This article lists new and significantly updated docs from the past three months. To learn what's new with the B2C service, see [What's new in Microsoft Entra ID](../active-directory/fundamentals/whats-new.md), [Azure AD B2C developer release notes](custom-policy-developer-notes.md) and [What's new in Microsoft Entra External ID](/entra/external-id/whats-new-docs).
 
+## June 2025
+
+### Updated articles
+
+- [Configure Cloudflare Web Application Firewall with Azure Active Directory B2C](partner-cloudflare.md) - Added a note about Azure Front Door-managed certificates
+- [Azure AD B2C: Frequently asked questions (FAQ)](faq.yml) - Updated the note in the Azure AD B2C end-of-sale section
+- [Page layout versions](page-layout.md) - Added updates related to CAPTCHA
+- [Securing phone-based multifactor authentication](phone-based-mfa.md) - Added information on preventing fraudulent sign-ups 
+
 ## April 2025
 
 ### Updated articles
@@ -32,12 +41,3 @@ This month, we added an important note to our articles stating that starting May
 ### Updated articles
 - [Error codes: Azure Active Directory B2C](error-codes.md) - Updated error messages
 
-## February 2025
-
-### Updated articles
-
-- [Enable multifactor authentication in Azure Active Directory B2C](multi-factor-authentication.md) - Added SMS pricing
-- [Page layout versions](page-layout.md) - Updated the latest versions of the self-asserted and MFA pages
-- [Azure AD B2C: Frequently asked questions (FAQ)](faq.yml) - Added billing name change for SMS phone
-- [Enable CAPTCHA in Azure Active Directory B2C](add-captcha.md) - Added CAPTCHA feature flag
-

articles/app-service/configure-authentication-user-identities.md

@@ -2,41 +2,48 @@
 title: Work with User Identities in AuthN/AuthZ
 description: Learn how to access user identities when you use the built-in authentication and authorization in Azure App Service.
 ms.topic: how-to
-ms.date: 03/29/2021
+ms.date: 07/02/2025
 ms.custom: AppServiceIdentity
 author: cephalin
 ms.author: cephalin
 ---
 
 # Work with user identities in Azure App Service authentication
 
-This article shows you how to work with user identities when you use built-in [authentication and authorization in Azure App Service](overview-authentication-authorization.md).
+This article shows you how to work with user identities when you use [built-in authentication and authorization](overview-authentication-authorization.md) in Azure App Service.
+
+## Prerequisites
+
+A web application running on Azure App Service that has the [App Service authentication/authorization module enabled](scenario-secure-app-authentication-app-service.md).
 
 ## Access user claims in app code
 
-For all language frameworks, App Service makes the claims in the incoming token (whether from an authenticated end user or from a client application) available to your code by injecting them into the request headers. External requests aren't allowed to set these headers, so they're present only if set by App Service.
+Your app's authenticated end users or client applications make claims in incoming tokens. App Service makes the claims available to your code by injecting them into request headers. External requests aren't allowed to set these headers, so they're present only if App Service sets them.
+
+You can use the claims information that App Service authentication provides to perform authorization checks in your app code. Code in any language or framework can get needed information from the request headers. Some code frameworks provide extra options that might be more convenient. See [Framework-specific alternatives](#framework-specific-alternatives).
 
-Some example headers are described in the following table:
+The following table describes some example headers:
 
 | Header                       | Description                                                           |
 |------------------------------|-----------------------------------------------------------------------|
 | `X-MS-CLIENT-PRINCIPAL`      | A Base64-encoded JSON representation of available claims. For more information, see [Decode the client principal header](#decode-the-client-principal-header).   |
-| `X-MS-CLIENT-PRINCIPAL-ID`   | An identifier for the caller, which the identity provider sets.            |
-| `X-MS-CLIENT-PRINCIPAL-NAME` | A human-readable name for the caller, set by the identity provider, such as an email address or a user principal name.   |
+| `X-MS-CLIENT-PRINCIPAL-ID`   | An identifier that the identity provider sets for the caller.            |
+| `X-MS-CLIENT-PRINCIPAL-NAME` | A human-readable name that the identity provider sets for the caller, such as an email address or user principal name.   |
 | `X-MS-CLIENT-PRINCIPAL-IDP`  | The name of the identity provider that App Service authentication uses. |
 
-Provider tokens are also exposed through similar headers. For example, Microsoft Entra also sets `X-MS-TOKEN-AAD-ACCESS-TOKEN` and `X-MS-TOKEN-AAD-ID-TOKEN` as appropriate.
+Similar headers expose [provider tokens](configure-authentication-oauth-tokens.md). For example, Microsoft Entra sets `X-MS-TOKEN-AAD-ACCESS-TOKEN` and `X-MS-TOKEN-AAD-ID-TOKEN` provider token headers as appropriate.
 
 > [!NOTE]
-> Different language frameworks might present these headers to the app code in different formats, such as in lowercase or by using title case.
-
-Code that is written in any language or framework can get the information that it needs from these headers. [Decode the client principal header](#decode-the-client-principal-header) covers this process. For some frameworks, the platform also provides extra options that might be more convenient.
+> App Service makes the request headers available to all language frameworks. Different language frameworks might present these headers to the app code in different formats, such as lowercase or title case.
 
 ### Decode the client principal header
 
-`X-MS-CLIENT-PRINCIPAL` contains the full set of available claims as Base64-encoded JSON. These claims go through a default claims-mapping process, so some might have different names than you would see if you processed the token directly.
+The `X-MS-CLIENT-PRINCIPAL` header contains the full set of available claims in Base64-encoded JSON. To process this header, your app must decode the payload and iterate through the `claims` array to find relevant claims.
+
+> [!NOTE]
+> These claims undergo a default claims-mapping process, so some names might be different than they appear in the tokens.
 
-Here's how the decoded payload is structured:
+The decoded payload structure is as follows:
 
 ```json
 {
@@ -52,16 +59,18 @@ Here's how the decoded payload is structured:
 }
 ```
 
+The following table describes the properties.
+
 | Property   | Type             | Description                           |
 |------------|------------------|---------------------------------------|
 | `auth_typ` | string           | The name of the identity provider that App Service authentication uses. |
-| `claims`   | array of objects | An array of objects that represent the available claims. Each object contains `typ` and `val` properties. |
-| `typ`      | string           | The name of the claim. It might be subject to default claims mapping and might be different from the corresponding claim that is contained in a token. |
+| `claims`   | array            | An array of objects that represent the available claims. Each object contains `typ` and `val` properties. |
+| `typ`      | string           | The name of the claim, which might be subject to default claims mapping and be different from the corresponding claim in the token. |
 | `val`      | string           | The value of the claim.                                      |
 | `name_typ` | string           | The name claim type, which is typically a URI that provides scheme information about the `name` claim if one is defined. |
 | `role_typ` | string           | The role claim type, which is typically a URI that provides scheme information about the `role` claim if one is defined. |
 
-To process this header, your app must decode the payload and iterate through the `claims` array to find relevant claims. It might be convenient to convert claims into a representation that the app's language framework uses. Here's an example of this process in C# that constructs a [`ClaimsPrincipal`](/dotnet/api/system.security.claims.claimsprincipal) type for the app to use:
+For convenience, you can convert claims into a representation that the app's language framework uses. The following C# example constructs a [`ClaimsPrincipal`](/dotnet/api/system.security.claims.claimsprincipal) type for the app to use.
 
 ```csharp
 using System;
@@ -106,17 +115,12 @@ public static class ClaimsPrincipalParser
             var json = Encoding.UTF8.GetString(decoded);
             principal = JsonSerializer.Deserialize<ClientPrincipal>(json, new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
         }
+```
+At this point, the code can iterate through `principal.Claims` to check claims as part of validation. Alternatively, you can convert `principal.Claims` into a standard object and use it to do those checks later in the request pipeline. You can also use that object to associate user data and for other uses.
 
-        /** 
-         *  At this point, the code can iterate through `principal.Claims` to
-         *  check claims as part of validation. Alternatively, you can convert
-         *  it into a standard object with which to perform those checks later
-         *  in the request pipeline. That object can also be leveraged for 
-         *  associating user data, and so on. The rest of this function performs such
-         *  a conversion to create a `ClaimsPrincipal` as might be used in 
-         *  other .NET code.
-         */
+The rest of the function performs this conversion to create a `ClaimsPrincipal` that can be used in other .NET code.
 
+```csharp
         var identity = new ClaimsIdentity(principal.IdentityProvider, principal.NameClaimType, principal.RoleClaimType);
         identity.AddClaims(principal.Claims.Select(c => new Claim(c.Type, c.Value)));
 
@@ -127,19 +131,24 @@ public static class ClaimsPrincipalParser
 
 ### Framework-specific alternatives
 
-For ASP.NET 4.6 apps, App Service populates [`ClaimsPrincipal.Current`](/dotnet/api/system.security.claims.claimsprincipal.current) with the authenticated user's claims. You can follow the standard .NET code pattern, including the [`Authorize`] attribute. Similarly, for PHP apps, App Service populates the `_SERVER['REMOTE_USER']` variable. For Java apps, the claims are [accessible from the Tomcat servlet](configure-language-java-security.md#authenticate-users-easy-auth).
+- For ASP.NET 4.6 apps, App Service populates [`ClaimsPrincipal.Current`](/dotnet/api/system.security.claims.claimsprincipal.current) with the authenticated user's claims. You can follow the standard .NET code pattern, including the `[Authorize]` attribute.
+
+  `ClaimsPrincipal.Current` isn't populated for .NET code in [Azure Functions](../azure-functions/functions-overview.md), but you can still find the user claims in the request headers, or get the `ClaimsPrincipal` object from the request context or through a binding parameter. For more information, see [Work with client identities in Azure Functions](../azure-functions/functions-bindings-http-webhook-trigger.md#working-with-client-identities).
+  
+- For PHP apps, App Service similarly populates the `_SERVER['REMOTE_USER']` variable.
 
-For [Azure Functions](../azure-functions/functions-overview.md), `ClaimsPrincipal.Current` isn't populated for .NET code, but you can still find the user claims in the request headers, or get the `ClaimsPrincipal` object from the request context or even through a binding parameter. For more information, see [Work with client identities in Azure Functions](../azure-functions/functions-bindings-http-webhook-trigger.md#working-with-client-identities).
+- For Java apps, the claims are accessible from the [Tomcat servlet](configure-language-java-security.md?pivots=java-tomcat#authenticate-users-easy-auth).
 
-For .NET Core, [`Microsoft.Identity.Web`](https://www.nuget.org/packages/Microsoft.Identity.Web/) supports populating the current user with App Service authentication. To learn more, review the [Microsoft.Identity.Web wiki](https://github.com/AzureAD/microsoft-identity-web/wiki/1.2.0#integration-with-azure-app-services-authentication-of-web-apps-running-with-microsoftidentityweb) or see it demonstrated in [this tutorial for a web app accessing Microsoft Graph](./scenario-secure-app-access-microsoft-graph-as-user.md?tabs=command-line#install-client-library-packages).
+- For .NET Core, [`Microsoft.Identity.Web`](https://www.nuget.org/packages/Microsoft.Identity.Web/) supports populating the current user with App Service authentication. For more information, see [Integration with Azure App Services authentication of web apps running with Microsoft.Identity.Web](https://github.com/AzureAD/microsoft-identity-web/wiki/1.2.0#integration-with-azure-app-services-authentication-of-web-apps-running-with-microsoftidentityweb). For a demonstration of a web app accessing Microsoft Graph, see [Tutorial: Access Microsoft Graph from a secured .NET app as the user](scenario-secure-app-access-microsoft-graph-as-user.md).
 
 > [!NOTE]
-> For claims mapping to work, you must enable the [token store](overview-authentication-authorization.md#token-store).
+> For claims mapping to work, you must enable the [token store](overview-authentication-authorization.md#token-store) for your app.
 
 ## Access user claims by using the API
 
-If the [token store](overview-authentication-authorization.md#token-store) is enabled for your app, you can also obtain other details on the authenticated user by calling `/.auth/me`.
+If the [token store](overview-authentication-authorization.md#token-store) is enabled for your app, you can also call `/.auth/me` to obtain other details on the authenticated user.
 
 ## Related content
 
+- [Authentication and authorization in Azure App Service and Azure Functions](overview-authentication-authorization.md)
 - [Tutorial: Authenticate and authorize users end to end](tutorial-auth-aad.md)

articles/app-service/overview-hosting-plans.md

@@ -4,7 +4,7 @@ description: Learn how App Service plans work in Azure App Service, how they're
 keywords: app service, azure app service, scale, scalable, scalability, app service plan, app service cost
 ms.assetid: dea3f41e-cf35-481b-a6bc-33d7fc9d01b1
 ms.topic: overview
-ms.date: 03/28/2025
+ms.date: 07/02/2025
 ms.update-cycle: 1095-days
 ms.author: msangapu
 author: msangapu-msft
@@ -123,7 +123,19 @@ However, keep in mind that apps in the same App Service plan all share the same
 
 Isolate your app in a new App Service plan when:
 
-- The app is resource intensive.
+- The app is resource intensive. For general guidance, use this table:
+
+  | App Service plan | Maximum apps |
+  |--|--|
+  | B1, S1, P1v2, I1v1 | 8 |
+  | B2, S2, P2v2, I2v1 | 16 |
+  | B3, S3, P3v2, I3v1 | 32 |
+  | P0v3 | 8 |
+  | P1v3, I1v2 | 16 |
+  | P2v3, I2v2, P1mv3 | 32 |
+  | P3v3, I3v2, P2mv3 | 64 |
+  | I4v2, I5v2, I6v2 | Maximum density bound by vCPU usage |
+  | P3mv3, P4mv3, P5mv3 | Maximum density bound by vCPU usage |
 - You want to scale the app independently from the other apps in the existing plan.
 - The app needs resources in a different geographical region. This way, you can allocate a new set of resources for your app and gain greater control of your apps.
 

articles/backup/azure-file-share-support-matrix.md

@@ -2,7 +2,7 @@
 title: Support Matrix for Azure files backup by using Azure Backup
 description: Provides a summary of support settings and limitations when backing up Azure files.
 ms.topic: reference
-ms.date: 05/23/2025
+ms.date: 07/03/2025
 ms.custom: references_regions, engagement-fy24
 ms.service: azure-backup
 author: jyothisuri
@@ -29,9 +29,9 @@ Azure files backup is available in all regions, **except** for Germany Central (
 
 # [Vault-standard tier](#tab/vault-tier)
 
-Vaulted backup for Azure Files is available in the following regions: UK South, UK West, Southeast Asia, East Asia, West Central US, Central US, Central India, North Europe, Australia East, West US, East US, South India, France Central, Canada Central, North Central US, East US 2, Australia Southeast, Germany North, France South, West US 2, Brazil South, Japan West, Germany West Central, Canada East, Korea South, Jio India West, Korea Central, South Africa West, Japan East, Norway East, Switzerland West, Norway West, South Africa North, UAE North, West Europe, Sweden Central, Switzerland North.
+Vaulted backup for Azure Files is available in the following regions: UK South, UK West, Southeast Asia, East Asia, West Central US, Central US, Central India, North Europe, Australia East, West US, East US, South India, France Central, Canada Central, North Central US, East US 2, Australia Southeast, Germany North, France South, West US 2, Brazil South, Japan West, Germany West Central, Canada East, Korea South, Jio India West, Korea Central, South Africa West, Japan East, Norway East, Switzerland West, Norway West, South Africa North, UAE North, West Europe, Sweden Central, Switzerland North, Sweden South, Brazil Southeast, UAE Central, Italy North, Jio India Central, West US 3, Australia Central, Australia Central 2.
 
-Cross Region Restore is currently supported in the following regions: Australia East, West US, North Central US, East US, East US2, West US2, South India, Australia Southeast, Brazil South, Canada East, Korea Central, Norway East, South Africa North, Switzerland North, France Central, Germany North, Japan West, Korea South, South Africa West, Switzerland West, Canada Central, France South, Germany West Central,  Japan East, Norway West, West Europe. This feature isn't supported in Sweden Central, UAE North, Jio India West.
+Cross Region Restore is supported in all preceding regions, except Italy North.
 
 Migration of  File Shares protected with snapshot backup to vaulted backup is supported in the following regions: UK South, UK West, Southeast Asia, East Asia, West Central US, and India Central.