change tip location & rewrite connectivity overview

Author: Cephas Lin

articles/app-service/tutorial-connect-overview.md

@@ -1,83 +1,86 @@
 ---
 title: 'Securely connect to Azure resources'
-description: Your app service may need to connect to other Azure services such as a database, storage, or another app. This overview recommends the more secure method for connecting.
+description: Shows you how to connect to other Azure services such as a database, storage, or another app. This overview recommends the more secure method for connecting.
 author: cephalin
 ms.author: cephalin
-
-ms.topic: tutorial
-ms.date: 01/16/2023
+ms.topic: article
+ms.date: 07/06/2024
 ms.custom: AppServiceConnectivity
+#customer intent: As a developer, I want to learn how to securely connect to Azure resources from Azure App Service so that I can protect sensitive data and ensure secure communication.
 ---
-# Securely connect to Azure services and databases from Azure App Service
+# Secure connectivity to Azure services and databases from Azure App Service
 
 Your app service may need to connect to other Azure services such as a database, storage, or another app. This overview recommends different methods for connecting and when to use them.
 
+Today, the decision for a connectivity approach is closely related to secrets management. The common pattern of using connection secrets in connection strings, such as username and password, secret key, etc. is no longer considered the most secure approach for connectivity. The risk is even higher today because threat actors regularly crawl public GitHub repositories for accidentally committed connection secrets. For cloud applications, the best secrets management is to have no secrets at all. When you migration to Azure App Service, your app might start with secrets-based connectivity, and App Service lets you keep secrets securely. However, Azure can help secure your app's back-end connectivity through Microsoft Entra authentication, which eliminates secrets altogether in your app.
+
 |Connection method|When to use|
 |--|--|
-|[Connect using the app identity](#connect-using-the-app-identity)|* You want to connect to a resource without an authenticated user present or using the app identity.<br>* You don't need to manage credentials, keys, or secrets, or the credentials aren’t even accessible to you.<br>* You can use managed identities to manage credentials for you.<br>* A Microsoft Entra identity is required to access the Azure resource. For example, services such as Microsoft Graph or Azure management SDKs.|
-|[Connect as the authenticated user](#connect-as-the-authenticated-user)| * You want to access a resource and perform some action as the signed-in user.|
-|[Connect using secrets](#connect-using-secrets)|* You need secrets to be passed to your app as environment variables.<br>* You want to connect to non-Azure services such as GitHub, Twitter, Facebook, or Google.<br>* The downstream resource doesn't support Microsoft Entra authentication.  <br>* The downstream resource requires a connection string or key or secret of some sort.|
-
-## Connect using secrets
+|[Connect using an app identity](#connect-using-an-app-identity)|* You want to remove credentials, keys, or secrets completely from your application.<br.>* The downstream Azure service supports Microsoft Entra authentication, such as Microsoft Graph.*<br/>The downstream resource doesn't need to know the current signed-in user or doesn't need granular authorization of the current signed-in user.|
+|[Connect on behalf of the signed-in user](#connect-on-behalf-of-the-signed-in-user)| * The app must access a downstream resource on behalf of the signed-in user.<br/>* The downstream Azure service supports Microsoft Entra authentication, such as Microsoft Graph.*<br/>The downstream resource must perform granular authorization of the current signed-in user.|
+|[Connect using secrets](#connect-using-secrets)|* The downstream resource requires connection secrets.<br>* Your app connects to non-Azure services, such as an on-premises database server.<br>* The downstream Azure service doesn't support Microsoft Entra authentication yet.|
 
-There are two recommended ways to use secrets in your app:  using secrets stored in Azure Key Vault or secrets in App Service application settings.
+## Connect with an app identity
 
-### Use secrets in app settings 
+If your app already uses a single set of credentials to access a downstream Azure service, you can very quickly convert the connection to use an app identity instead. A [managed identity](overview-managed-identity.md) from Microsoft Entra ID lets App Service access resources without secrets, and you can manage its access through role-based access control (RBAC). A managed identity can connect to any Azure resource that supports Microsoft Entra authentication, and the authentication takes place with short-lived tokens.
 
-Some apps access secrets using environment variables.  Traditionally, App Service [app settings](configure-common.md) have been used to store connection strings, API keys, and other environment variables.  These secrets are injected into your application code as environment variables at app startup. App settings are always encrypted when stored (encrypted-at-rest).  If you also want access policies and audit history for your secrets, consider putting them in Azure Key Vault and using [Key Vault references](app-service-key-vault-references.md) in your app settings.
+The following image demonstrates the following an App Service connecting to other Azure services:
 
-Examples of using application secrets to connect to a database:
+* A: User visits Azure app service website.
+* B: Securely **connect from** App Service **to** another Azure service using a managed identity. 
+* C: Securely **connect from** App Service **to** Microsoft Graph using a managed identity.
 
-- [ASP.NET Core with SQL DB](tutorial-dotnetcore-sqldb-app.md)
-- [ASP.NET with SQL DB](app-service-web-tutorial-dotnet-sqldatabase.md)
-- [PHP with MySQL](tutorial-php-mysql-app.md)
-- [Node.js with MongoDB](tutorial-nodejs-mongodb-app.md)
-- [Python with Postgres](tutorial-python-postgresql-app.md)
-- [Java with Spring Data](tutorial-java-spring-cosmosdb.md)
-- [Quarkus with Postgres](tutorial-java-quarkus-postgresql-app.md)
+:::image type="content" source="media/scenario-secure-app-overview/web-app.svg" alt-text="Diagram showing managed identity accessing a resource with or without the user's identity.":::
 
-### Use secrets from Key Vault
+## Connect on behalf of the signed-in user
 
-[Azure Key Vault](app-service-key-vault-references.md) can be used to securely store secrets and keys, monitor access and use of secrets, and simplify administration of application secrets.  If your app's downstream service doesn't support Microsoft Entra authentication or requires a connection string or key, use Key Vault to store your secrets and connect your app to Key Vault with a managed identity and retrieve the secrets. 
+Your app might need to connect to a downstream service on behalf of the signed-in user. App Service lets you easily authenticate users using the most common identity providers (see [Authentication and authorization in Azure App Service and Azure Functions](overview-authentication-authorization.md)). If you use the Microsoft provider (Microsoft Entra authentication), you can then flow this signed-in user to any downstream service. For example:
 
-Benefits of managed identities integrated with Key Vault include:
-- Access to the Key Vault is restricted to the app. 
-- App contributors, such as administrators, may have complete control of the App Service resources, and at the same time have no access to the Key Vault secrets. 
-- No code change is required if your application code already accesses connection secrets with app settings. 
-- Key Vault provides monitoring and auditing of who accessed secrets.  
-- Rotation of connection information in Key Vault requires no changes in App Service.
+- In SQL database, run a query that returns confidential data that the signed-in user is authorized to read.
+- Retrieve personal data or take actions as the signed-in user in Microsoft Graph.
 
-The following image demonstrates App Service connecting to Key Vault using a managed identity and then accessing an Azure service using secrets stored i Key Vault:
+The following image demonstrates an application securely accessing an SQL database on behalf of the signed-in user.
 
-:::image type="content" source="media/tutorial-connect-overview/app-service-connect-key-vault-managed-identity.png" alt-text="Image showing app service using a secret stored in Key Vault and managed with Managed identity to connect to Azure AI services."::: 
+:::image type="content" source="./media/tutorial-connect-app-access-sql-database-as-user-dotnet/architecture.png" alt-text="Architecture diagram for tutorial scenario.":::
 
+Some common scenarios are:
+- [Connect to Microsoft Graph on behalf of the user](scenario-secure-app-access-microsoft-graph-as-user.md)
+- [Connect to an SQL database on behalf the user](tutorial-connect-app-access-sql-database-as-user-dotnet.md)
+- [Connect to another App Service app on behalf of the user](tutorial-auth-aad.md)
+- [Flow the signed-in user through multiple layers of downstream services](tutorial-connect-app-app-graph-javascript.md)
 
-## Connect using the app identity
+## Connect using secrets
 
-In some cases, your app needs to access data under the identity of the app itself or without a signed-in user present. A [managed identity](overview-managed-identity.md) from Microsoft Entra ID allows App Service to access resources through role-based access control (RBAC), without requiring app credentials.  A managed identity can connect to any resource that supports Microsoft Entra authentication. After assigning a managed identity to your web app, Azure takes care of the creation and distribution of a certificate. You don't have to worry about managing secrets or app credentials.
+There are two recommended ways to use secrets in your app: using secrets stored in Azure Key Vault or secrets in App Service app settings.
 
-The following image demonstrates the following an App Service connecting to other Azure services:
+### Use secrets from Key Vault
 
-* A: User visits Azure app service website.
-* B: Securely **connect from** App Service **to** another Azure service using a managed identity. 
-* C: Securely **connect from** App Service **to** Microsoft Graph using a managed identity.
+[Azure Key Vault](app-service-key-vault-references.md) can be used to securely store secrets and keys, monitor access and use of secrets, and simplify administration of application secrets. If the downstream service doesn't support Microsoft Entra authentication or requires a connection string or key, use Key Vault to store your secrets and connect your app to Key Vault with a managed identity and retrieve the secrets. Your app can access they key vault secrets as [Key Vault references](app-service-key-vault-references.md) in the app settings. 
 
-:::image type="content" source="media/scenario-secure-app-overview/web-app.svg" alt-text="Diagram showing managed identity accessing a resource with or without the user's identity.":::
+Benefits of managed identities integrated with Key Vault include:
+- Access to the key vault secret is restricted to the app. 
+- App contributors, such as administrators, may have complete control of the App Service resources, and at the same time have no access to the key vault secrets. 
+- No code change is required if your application code already accesses connection secrets with app settings. 
+- Key Vault provides monitoring and auditing of who accessed secrets.
+- Rotation of key vault secrets requires no changes in App Service.
 
-## Connect as the authenticated user
+The following image demonstrates App Service connecting to Key Vault using a managed identity and then accessing an Azure service using secrets stored in Key Vault:
 
-In some cases, your app needs to connect to a resource and perform some action that only the signed-in user can do. Grant delegated permissions to your app to connect to resources using the identity of the signed-in user.
+:::image type="content" source="media/tutorial-connect-overview/app-service-connect-key-vault-managed-identity.png" alt-text="Image showing app service using a secret stored in Key Vault and managed with Managed identity to connect to Azure AI services."::: 
 
-The following image demonstrates an application securely accessing an SQL database on behalf of the signed-in user.
+### Use secrets in app settings 
 
-:::image type="content" source="./media/tutorial-connect-app-access-sql-database-as-user-dotnet/architecture.png" alt-text="Architecture diagram for tutorial scenario.":::
+For apps that connect to services using secrets (such as usernames, passwords, and API keys), App Service can store them securely in [app settings](configure-common.md). These secrets are injected into your application code as environment variables at app startup. App settings are always encrypted when stored (encrypted-at-rest). For more advanced secrets management, such as secrets rotation, access policies, and audit history, try [using Key Vault](#use-secrets-from-key-vault).
 
-Some common scenarios are:
-- [Connect to Microsoft Graph](scenario-secure-app-access-microsoft-graph-as-user.md) as the user
-- [Connect to an SQL database](tutorial-connect-app-access-sql-database-as-user-dotnet.md) as the user
-- [Connect to another App Service app](tutorial-auth-aad.md) as the user
-- [Connect to another App Service app and then a downstream service](tutorial-connect-app-app-graph-javascript.md) as the user
+Examples of using application secrets to connect to a database:
 
+- [ASP.NET Core with SQL DB](tutorial-dotnetcore-sqldb-app.md)
+- [ASP.NET with SQL DB](app-service-web-tutorial-dotnet-sqldatabase.md)
+- [PHP with MySQL](tutorial-php-mysql-app.md)
+- [Node.js with MongoDB](tutorial-nodejs-mongodb-app.md)
+- [Python with Postgres](tutorial-python-postgresql-app.md)
+- [Java with Spring Data](tutorial-java-spring-cosmosdb.md)
+- [Quarkus with Postgres](tutorial-java-quarkus-postgresql-app.md)
 
 ## Next steps
 

articles/app-service/tutorial-dotnetcore-sqldb-app.md

@@ -159,6 +159,9 @@ Sign in to the [Azure portal](https://portal.azure.com/) and follow these steps
 
 ## 2. Verify connection strings
 
+> [!TIP]
+> The default SQL database connection string uses SQL authentication. For more secure, passwordless authentication, see [How do I change the SQL Database connection to use a managed identity instead?](#how-do-i-change-the-sql-database-connection-to-use-a-managed-identity-instead) 
+
 The creation wizard generated connection strings for the SQL database and the Redis cache already. In this step, find the generated connection strings for later.
 
 :::row:::
@@ -182,9 +185,6 @@ The creation wizard generated connection strings for the SQL database and the Re
     :::column-end:::
 :::row-end:::
 
-> [!TIP]
-> The default SQL database connection string uses SQL authentication. For more secure, passwordless authentication, see [How do I change the SQL Database connection to use a managed identity instead?](#how-do-i-change-the-sql-database-connection-to-use-a-managed-identity-instead) 
-
 ## 3. Deploy sample code
 
 In this step, you configure GitHub deployment using GitHub Actions. It's just one of many ways to deploy to App Service, but also a great way to have continuous integration in your deployment process. By default, every `git push` to your GitHub repository kicks off the build and deploy action.
@@ -467,6 +467,9 @@ Having issues? Check the [Troubleshooting section](#troubleshooting).
 
 ## 3. Verify connection strings
 
+> [!TIP]
+> The default SQL database connection string uses SQL authentication. For more secure, passwordless authentication, see [How do I change the SQL Database connection to use a managed identity instead?](#how-do-i-change-the-sql-database-connection-to-use-a-managed-identity-instead) 
+
 The AZD template you use generated the connectivity variables for you already as [app settings](configure-common.md#configure-app-settings) and outputs the them to the terminal for your convenience. App settings are one way to keep connection secrets out of your code repository.
 
 1. In the AZD output, find the settings `AZURE_SQL_CONNECTIONSTRING` and `AZURE_REDIS_CONNECTIONSTRING`. To keep secrets safe, only the setting names are displayed. They look like this in the AZD output:
@@ -482,9 +485,6 @@ The AZD template you use generated the connectivity variables for you already as
 
 1. For your convenience, the AZD template shows you the direct link to the app's app settings page. Find the link and open it in a new browser tab.
 
-> [!TIP]
-> The default SQL database connection string uses SQL authentication. For more secure, passwordless authentication, see [How do I change the SQL Database connection to use a managed identity instead?](#how-do-i-change-the-sql-database-connection-to-use-a-managed-identity-instead) 
-
 Having issues? Check the [Troubleshooting section](#troubleshooting).
 
 ## 4. Modify sample code and redeploy
@@ -713,7 +713,7 @@ Your app should now have connectivity to the SQL database. For more information,
 > [!TIP]
 > **Don't want to enable public network connection?** You can skip `az sql server update --enable-public-network true` by running the commands from an [Azure cloud shell that's integrated with your virtual network](../cloud-shell/vnet/deployment.md) if you have the **Owner** role assignment on your subscription. 
 > 
-> To grant the identity the required access to the database that's secured by the virtual network, `az webapp connection create sql` needs direct connectivity to the database server.
+> To grant the identity the required access to the database that's secured by the virtual network, `az webapp connection create sql` needs direct connectivity with Entra ID authentication to the database server. By default, the Azure cloud shell doesn't have this access to the network-secured database.
 
 ### What can I do with GitHub Copilot in my codespace?