Merge branch 'MicrosoftDocs:main' into mc-user-assigned-identity

Author: MutemwaRMasheke

articles/active-directory-b2c/partner-asignio.md

@@ -6,7 +6,7 @@ author: gargi-sinha
 manager: martinco
 ms.service: active-directory
 ms.topic: how-to
-ms.date: 06/21/2024
+ms.date: 10/03/2024
 ms.author: gasinh
 ms.reviewer: kengaderdus
 ms.subservice: B2C
@@ -65,7 +65,7 @@ The following diagram illustrates the implementation.
 
 1. User opens Azure AD B2C sign in page on their mobile or web application, and then signs in or signs up.
 2. Azure AD B2C redirects the user to Asignio using an OpenID Connect (OIDC) request.
-3. The user is redirected to the Asignio web application for biometric sign in. If the user hasn't registered their Asignio Signature, they can use an SMS One-Time-Password (OTP) to authenticate. After authentication, user receives a registration link to create their Asignio Signature.
+3. The user is redirected to the Asignio web application for biometric sign in. If the user didn't register their Asignio Signature, they can use an SMS One-Time-Password (OTP) to authenticate. After authentication, user receives a registration link to create their Asignio Signature.
 4. The user authenticates with Asignio Signature and facial verification, or voice and facial verification.
 5. The challenge response goes to Asignio. 
 6. Asignio returns the OIDC response to Azure AD B2C sign in.
@@ -76,11 +76,11 @@ The following diagram illustrates the implementation.
 
 Configurating an application with Asignio is with the Asignio Partner Administration site. 
 
-1. Go to asignio.com [Asignio Partner Administration](https://partner.asignio.com) page to request access for your organization. 
+1. To request access for your organization, go to asignio.com [Asignio Partner Administration](https://partner.asignio.com) page. 
 2. With credentials, sign into Asignio Partner Administration.
 3. Create a record for the Azure AD B2C application using your Azure AD B2C tenant. When you use Azure AD B2C with Asignio, Azure AD B2C manages connected applications. Asignio apps represent apps in the Azure portal.
 4. In the Asignio Partner Administration site, generate a Client ID and Client Secret. 
-5. Note and store Client ID and Client Secret. You'll use them later. Asignio doesn't store Client Secrets.
+5. Note and store Client ID and Client Secret. You use them later. Asignio doesn't store Client Secrets.
 6. Enter the redirect URI in your site the user is returned to after authentication. Use the following URI pattern.
 
 `[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp]`.
@@ -99,6 +99,9 @@ For this tutorial, you're registering  `https://jwt.ms`, a Microsoft web applica
 
 Complete [Tutorial: Register a web application in Azure Active Directory B2C](tutorial-register-applications.md?tabs=app-reg-ga)
 
+>[!NOTE]
+>Enable implicit flow only for testing purposes. Don’t enable implicit flow in production.
+
 ## Configure Asignio as an identity provider in Azure AD B2C
 
 For the following instructions, use the Microsoft Entra tenant with the Azure subscription.

articles/active-directory-b2c/partner-trusona.md

@@ -6,7 +6,7 @@ author: gargi-sinha
 manager: martinco
 ms.service: active-directory
 ms.topic: how-to
-ms.date: 01/26/2024
+ms.date: 10/03/2024
 ms.author: gasinh
 ms.subservice: B2C
 
@@ -40,7 +40,7 @@ The following diagram shows the architecture.
 
 ![Diagram of the xID architecture.](./media/partner-xid/partner-xid-architecture-diagram.png)
 
-1. At the Azure AD B2C sign-in page user signs in or signs up.
+1. At the Azure AD B2C sign-in page, the user signs in or signs up.
 2. Azure AD B2C redirects the user to xID authorize API endpoint using an OpenID Connect (OIDC) request. An OIDC endpoint has endpoint information. xID identity provider (IdP) redirects the user to the xID authorization sign in page. User enters email address.
 3. xID IdP sends push notification to user mobile device.
 4. User opens the xID app, checks the request, enters a PIN, or uses biometrics. xID app activates the private key and creates an electronic signature.
@@ -56,7 +56,7 @@ The following diagram shows the architecture.
 
 ## Install xID
 
-1. To request API documents, fill out the request form.  Go to [Contact Us](https://xid.inc/contact-us). 
+1. To request API documents, fill out the request form. Go to [Contact Us](https://xid.inc/contact-us). 
 2. In the message, indicate you're using Azure AD B2C. 
 3. An xID sales representative contacts you. 
 4. Follow the instructions in the xID API document.
@@ -78,6 +78,9 @@ For testing, you register `https://jwt.ms`, a Microsoft web application with dec
 
 Complete [Tutorial: Register a web application in Azure AD B2C](tutorial-register-applications.md?tabs=app-reg-ga) 
 
+>[!NOTE]
+>Enable implicit flow only for testing purposes. Don’t enable implicit flow in production.
+
 <a name='create-a-xid-policy-key'></a>
 
 ## Create an xID policy key
@@ -407,7 +410,7 @@ There are identity claims xID supports referenced as part of the policy. Claims
 
 The relying party policy, for example [SignUpSignIn.xml](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/main/LocalAccounts/SignUpOrSignin.xml), specifies the user journey the Azure AD B2C executes. 
 
-1. In the relying party,locate the **DefaultUserJourney** element. 
+1. In the relying party, locate the **DefaultUserJourney** element. 
 2. Update the **ReferenceId** to match the user journey ID you added to the identity provider.
 
 In the following example, for the xID user journey, the **ReferenceId** is set to `CombinedSignInAndSignUp`.

articles/active-directory-b2c/partner-xid.md

@@ -4,7 +4,7 @@ description: Learn to configure common settings for an App Service app. App sett
 keywords: azure app service, web app, app settings, environment variables
 ms.assetid: 9af8a367-7d39-4399-9941-b80cbc5f39a0
 ms.topic: article
-ms.date: 06/04/2024
+ms.date: 10/03/2024
 ms.custom: devx-track-csharp, devx-track-azurecli, devx-track-azurepowershell, AppServiceConnectivity
 ms.devlang: azurecli
 author: cephalin
@@ -446,7 +446,8 @@ Here, you can configure some common settings for the app. Some settings require
     - **Always On**: Keeps the app loaded even when there's no traffic. When **Always On** isn't turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When **Always On** is turned on, the front-end load balancer sends a GET request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
 
         Always On is required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.
-    - **ARR affinity**: In a multi-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to **Off** for stateless applications.
+    - **Session affinity**: In a multi-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to **Off** for stateless applications.
+    - **Session affinity proxy**: Session affinity proxy can be turned on if your app is behind a reverse proxy (like Azure Application Gateway or Azure Front Door) and you are using the default host name. The domain for the session affinity cookie will align with the forwarded host name from the reverse proxy. 
     - **HTTPS Only**: When enabled, all HTTP traffic is redirected to HTTPS.
     - **Minimum TLS version**: Select the minimum TLS encryption version required by your app.
 - **Debugging**: Enable remote debugging for [ASP.NET](troubleshoot-dotnet-visual-studio.md#remotedebug), [ASP.NET Core](/visualstudio/debugger/remote-debugging-azure), or [Node.js](configure-language-nodejs.md#debug-remotely) apps. This option turns off automatically after 48 hours.

articles/app-service/configure-common.md

@@ -547,7 +547,7 @@ Here are some common swap errors:
 
 - Local cache initialization might fail when the app content exceeds the local disk quota specified for the local cache. For more information, see [Local cache overview](overview-local-cache.md).
 
-- During a site update operation, the following error may occur "_The slot cannot be changed because its configuration settings have been prepared for swap_". This can occur if either [swap with preview (multi-phase swap)](#swap-with-preview-multi-phase-swap) phase 1 has been completed but phase 2 has not yet been performed, or a swap has failed. There are two ways resolve the issue:
+- During a site update operation, the following error may occur "_The slot cannot be changed because its configuration settings have been prepared for swap_". This can occur if either [swap with preview (multi-phase swap)](#swap-with-preview-multi-phase-swap) phase 1 has been completed but phase 2 has not yet been performed, or a swap has failed. There are two ways to resolve this issue:
 
     1. Cancel the swap operation which will reset the site back to the old state
     1. Complete the swap operation which will update site to the desired new state

articles/app-service/deploy-staging-slots.md

@@ -11,6 +11,9 @@ ms.collection: ce-skilling-ai-copilot
 ---
 # Azure App Service TLS overview
 
+> [!NOTE]
+> Customers may be aware of [the retirement notification of TLS 1.0 and 1.1 for interactions with Azure services](https://azure.microsoft.com/updates/azure-support-tls-will-end-by-31-october-2024-2/). This retirement does not affect applications running on App Service or Azure Functions.  Applications on either App Service or Azure Functions configured to accept TLS 1.0 or TLS 1.1 for incoming requests will continue to run unaffected.
+
 ## What does TLS do in App Service?
 
 Transport Layer Security (TLS) is a widely adopted security protocol designed to secure connections and communications between servers and clients. App Service allows customers to use TLS/SSL certificates to secure incoming requests to their web apps. App Service currently supports different set of TLS features for customers to secure their web apps. 
@@ -29,6 +32,17 @@ Transport Layer Security (TLS) is a widely adopted security protocol designed to
 
 For incoming requests to your web app, App Service supports TLS versions 1.0, 1.1, 1.2, and 1.3.  
 
+### Set Minimum TLS Version
+Follow these steps to change the Minimum TLS version of your App Service resource:
+1. Browse to your app in the [Azure portal](https://portal.azure.com/) 
+1. In the left menu, select **configuration** and then select the **General settings** tab. 
+1. On __Minimum Inbound TLS Version__, using the dropdown, select your desired version. 
+1. Select **Save** to save the changes. 
+
+### Minimum TLS Version with Azure Policy 
+
+You can use Azure Policy to help audit your resources when it comes to minimum TLS version. You can refer to [App Service apps should use the latest TLS version policy definition](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff0e6e85b-9b9f-4a4b-b67b-f730d42f1b0b) and change the values to your desired minimum TLS version. For similar policy definitions for other App Service resources, refer to [List of built-in policy definitions - Azure Policy for App Service](../governance/policy/samples/built-in-policies.md#app-service). 
+
 ### Minimum TLS Version and SCM Minimum TLS Version 
 
 App Service also allows you to set minimum TLS version for incoming requests to your web app and to SCM site. By default, the minimum TLS version for incoming requests to your web app and to SCM would be set to 1.2 on both portal and API. 

articles/app-service/overview-tls.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
 ms.topic: conceptual
-ms.date: 09/30/2023
+ms.date: 10/03/2024
 ms.author: greglin
 ---
 
@@ -26,7 +26,7 @@ The [Chromium browser](https://www.chromium.org/Home) [v80 update](https://chrom
 
 To support this change, starting February 17 2020, Application Gateway (all the SKU types) will inject another cookie called *ApplicationGatewayAffinityCORS* in addition to the existing *ApplicationGatewayAffinity* cookie. The *ApplicationGatewayAffinityCORS* cookie has two more attributes added to it (*"SameSite=None; Secure"*) so that sticky sessions are maintained even for cross-origin requests.
 
-Note that the default affinity cookie name is *ApplicationGatewayAffinity* and you can change it. If you deploy multiple application gateway instances in the same network topology, you must set unique cookie names for each instance. If you're using a custom affinity cookie name, an additional cookie is added with `CORS` as suffix. For example: *CustomCookieNameCORS*.
+Note that the default affinity cookie name is *ApplicationGatewayAffinity* and you can change it. If in your network topology, you deploy multiple application gateways in line, you must set unique cookie names for each resource. If you're using a custom affinity cookie name, an additional cookie is added with `CORS` as suffix. For example: *CustomCookieNameCORS*.
 
 > [!NOTE]
 > If the attribute *SameSite=None* is set, it is mandatory that the cookie also contains the *Secure* flag, and must be sent over HTTPS.  If session affinity is required over CORS, you must migrate your workload to HTTPS. 
@@ -35,8 +35,7 @@ Please refer to TLS offload and End-to-End TLS documentation for Application Gat
 ## Connection draining
 
 Connection draining helps you gracefully remove backend pool members during planned service updates. It applies to backend instances that are 
-- explicitly removed from the backend pool,
-- removed during scale-in operations, or
+- explicitly removed from the backend pool, or
 - reported as unhealthy by the health probes.
 
 You can apply this setting to all backend pool members by enabling Connection Draining in the Backend Setting. It ensures that all deregistering instances in a backend pool don't receive any new requests/connections while maintaining the existing connections until the configured timeout value. This is also true for WebSocket connections.

articles/application-gateway/configuration-http-settings.md

@@ -105,9 +105,8 @@ For more information, see [WebSocket support](application-gateway-websocket.md)
 ## Connection draining
 
 Connection draining helps you achieve graceful removal of backend pool members during planned service updates or problems with backend health. This setting is enabled via the [Backend Setting](configuration-http-settings.md) and is applied to all backend pool members during rule creation. Once enabled, the application gateway ensures all deregistering instances of a backend pool don't receive any new requests while allowing existing requests to complete within a configured time limit. It applies to cases where backend instances are:
-- explicitly removed from the backend pool after a configuration change by a user
-- reported as unhealthy by the health probes, or
-- removed during a scale-in operation
+- explicitly removed from the backend pool after a configuration change by a user, or
+- reported as unhealthy by the health probes
 
 The only exception is when requests continue to be proxied to the deregistering instances because of gateway-managed session affinity.