Configure passwordless connections between multiple Azure apps and services
Article
Applications often require secure connections between multiple Azure services simultaneously. For example, an enterprise Azure App Service instance might connect to several different storage accounts, an Azure SQL database instance, a Service Bus, and more.
Managed identities are the recommended authentication option for secure, passwordless connections between Azure resources. Developers don't have to manually track and manage many different secrets for managed identities, since most of these tasks are handled internally by Azure. This tutorial explores how to manage connections between multiple services using managed identities and the Azure Identity client library.
Compare the types of managed identities
Azure provides the following types of managed identities:
System-assigned managed identities are directly tied to a single Azure resource. When you enable a system-assigned managed identity on a service, Azure will create a linked identity and handle administrative tasks for that identity internally. When the Azure resource is deleted, the identity is also deleted.
User-assigned managed identities are independent identities that are created by an administrator and can be associated with one or more Azure resources. The lifecycle of the identity is independent of those resources.
Managed identities are most easily implemented in your application code via a class called DefaultAzureCredential from the Azure Identity client library. DefaultAzureCredential supports multiple authentication mechanisms and automatically determines which should be used at runtime. Learn more about DefaultAzureCredential for the following ecosystems:
Connect an Azure-hosted app to multiple Azure services
Imagine you're tasked with connecting an existing app to multiple Azure services and databases using passwordless connections. The application is an ASP.NET Core Web API hosted on Azure App Service, though the steps below apply to other Azure hosting environments as well, such as Azure Spring Apps, Virtual Machines, Container Apps, and AKS.
This tutorial applies to the following architectures, though it can be adapted to many other scenarios as well through minimal configuration changes.
The following steps demonstrate how to configure an app to use a system-assigned managed identity and your local development account to connect to multiple Azure Services.
Create a system-assigned managed identity
In the Azure portal, navigate to the hosted application that you would like to connect to other services.
On the service overview page, select Identity.
Toggle the Status setting to On to enable a system assigned managed identity for the service.
Assign roles to the managed identity for each connected service
Navigate to the overview page of the storage account you would like to grant access your identity access to.
Select Access Control (IAM) from the storage account navigation.
Choose + Add and then Add role assignment.
In the Role search box, search for Storage Blob Data Contributor, which grants permissions to perform read and write operations on blob data. You can assign whatever role is appropriate for your use case. Select the Storage Blob Data Contributor from the list and choose Next.
On the Add role assignment screen, for the Assign access to option, select Managed identity. Then choose +Select members.
In the flyout, search for the managed identity you created by entering the name of your App Service. Select the system-assigned identity, and then choose Select to close the flyout menu.
Select Next a couple times until you're able to select Review + assign to finish the role assignment.
Repeat this process for the other services you would like to connect to.
Local development considerations
You can also enable access to Azure resources for local development by assigning roles to a user account the same way you assigned roles to your managed identity.
After assigning the Storage Blob Data Contributor role to your managed identity, under Assign access to, this time select User, group or service principal. Choose + Select members to open the flyout menu again.
Search for the user@domain account or Microsoft Entra security group you would like to grant access to by email address or name, and then select it. This should be the same account you use to sign-in to your local development tooling with, such as Visual Studio or the Azure CLI.
Note
You can also assign these roles to a Microsoft Entra security group if you're working on a team with multiple developers. You can then place any developer inside that group who needs access to develop the app locally.
In your project, install the Azure.Identity package. This library provides DefaultAzureCredential. You can also add any other Azure libraries that are relevant to your app. For this example, the Azure.Storage.Blobs and Azure.Messaging.ServiceBus packages are added to connect to Blob Storage and Service Bus, respectively.
Instantiate service clients for the Azure services to which your app must connect. The following code sample interacts with Blob Storage and Service Bus using the corresponding service clients.
using Azure.Identity;
using Azure.Messaging.ServiceBus;
using Azure.Storage.Blobs;
// Create DefaultAzureCredential instance that uses system-assigned managed identity
// in the underlying ManagedIdentityCredential.
DefaultAzureCredential credential = new();
BlobServiceClient blobServiceClient = new(
new Uri("https://<your-storage-account>.blob.core.windows.net"),
credential);
ServiceBusClient serviceBusClient = new("<your-namespace>", credential);
ServiceBusSender sender = serviceBusClient.CreateSender("producttracking");
In your project, add the azure-identity dependency to your pom.xml file. This library provides DefaultAzureCredential. You can also add any other Azure dependencies that are relevant to your app. For this example, the azure-storage-blob and azure-messaging-servicebus dependencies are added to interact with Blob Storage and Service Bus.
Instantiate service clients for the Azure services to which your app must connect. The following code sample interacts with Blob Storage and Service Bus using the corresponding service clients.
class Demo {
public static void main(String[] args) {
// Create DefaultAzureCredential instance that uses system-assigned managed identity
// in the underlying ManagedIdentityCredential.
DefaultAzureCredential credential = new DefaultAzureCredentialBuilder()
.build();
BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
.endpoint("https://<your-storage-account>.blob.core.windows.net")
.credential(credential)
.buildClient();
ServiceBusClientBuilder clientBuilder = new ServiceBusClientBuilder()
.credential(credential);
ServiceBusSenderClient serviceBusSenderClient = clientBuilder.sender()
.queueName("producttracking")
.buildClient();
}
}
In your project, you only need to add service dependencies you use. For this example, the spring-cloud-azure-starter-storage-blob and spring-cloud-azure-starter-servicebus dependencies are added in order to connect to Blob Storage and Service Bus.
Instantiate service clients for the Azure services to which your app must connect. The following examples connect to Blob Storage and Service Bus using the corresponding service clients.
@Service
public class ExampleService {
@Autowired
private BlobServiceClient blobServiceClient;
@Autowired
private ServiceBusSenderClient serviceBusSenderClient;
}
In your project, install the @azure/identity package. This library provides DefaultAzureCredential. For this example, the @azure/storage-blob and @azure/service-bus packages are installed to interact with Blob Storage and Service Bus.
Instantiate service clients for the Azure services to which your app must connect. The following code sample interacts with Blob Storage and Service Bus using the corresponding service clients.
import { DefaultAzureCredential } from "@azure/identity";
import { BlobServiceClient } from "@azure/storage-blob";
import { ServiceBusClient } from "@azure/service-bus";
// Azure resource names
const storageAccount = process.env.AZURE_STORAGE_ACCOUNT_NAME;
const serviceBusNamespace = process.env.AZURE_SERVICE_BUS_NAMESPACE;
// Create DefaultAzureCredential instance that uses system-assigned managed identity
// in the underlying ManagedIdentityCredential.
const credential = new DefaultAzureCredential();
// Create client for Blob Storage
const blobServiceClient = new BlobServiceClient(
`https://${storageAccount}.blob.core.windows.net`,
credential
);
// Create client for Service Bus
const serviceBusClient = new ServiceBusClient(
`https://${serviceBusNamespace}.servicebus.windows.net`,
credential
);
In your project, add a reference to the azure-identity package. This library provides DefaultAzureCredential. You can also add any other Azure libraries that are relevant to your app. For this example, the azure-storage-blob and azure-service-bus packages are added to connect to Blob Storage and Service Bus, respectively.
Instantiate service clients for the Azure services to which your app must connect. The following code sample interacts with Blob Storage and Service Bus using the corresponding service clients.
from azure.identity import DefaultAzureCredential
from azure.servicebus import ServiceBusClient, ServiceBusMessage
from azure.storage.blob import BlobServiceClient
import os
# Create DefaultAzureCredential instance that uses system-assigned managed identity
# in the underlying ManagedIdentityCredential.
credential = DefaultAzureCredential()
blob_service_client = BlobServiceClient(
account_url="https://<my-storage-account-name>.blob.core.windows.net/",
credential=credential
)
fully_qualified_namespace = os.environ['SERVICEBUS_FULLY_QUALIFIED_NAMESPACE']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']
with ServiceBusClient(fully_qualified_namespace, credential) as service_bus_client:
with service_bus_client.get_queue_sender(queue_name) as sender:
# Sending a single message
single_message = ServiceBusMessage("Single message")
sender.send_messages(single_message)
When this code runs locally, DefaultAzureCredential searches its credential chain for the first available credentials. If the Managed_Identity_Client_ID environment variable is null locally, a credential corresponding to a locally installed developer tool is used. For example, Azure CLI or Visual Studio. To learn more about this process, see section Explore DefaultAzureCredential.
When the application is deployed to Azure, DefaultAzureCredential automatically retrieves the Managed_Identity_Client_ID variable from the App Service environment. That value becomes available when a managed identity is associated with your app.
This overall process ensures that your app can run securely locally and in Azure without the need for any code changes.
Connect multiple apps using multiple managed identities
Although the apps in the previous example shared the same service access requirements, real-world environments are often more nuanced. Consider a scenario where multiple apps connect to the same storage accounts, but two of the apps also access different services or databases.
To configure this setup in your code, ensure your application registers separate service clients to connect to each storage account or database. Reference the correct managed identity client IDs for each service when configuring DefaultAzureCredential. The following code samples configure these Azure service connections:
Two connections to separate storage accounts using a shared user-assigned managed identity
A connection to Azure Cosmos DB and Azure SQL services using a second user-assigned managed identity. This managed identity is shared when the Azure SQL client driver allows for it. For more information, see the code comments.
class Demo {
public static void main(String[] args) {
String clientIdStorage = System.getenv("Managed_Identity_Client_ID_Storage");
// Create a DefaultAzureCredential instance that configures the underlying
// ManagedIdentityCredential to use a user-assigned managed identity.
DefaultAzureCredential credentialStorage = new DefaultAzureCredentialBuilder()
.managedIdentityClientId(clientIdStorage)
.build();
// First Blob Storage client
BlobServiceClient blobServiceClient1 = new BlobServiceClientBuilder()
.endpoint("https://<receipt-storage-account>.blob.core.windows.net")
.credential(credentialStorage)
.buildClient();
// Second Blob Storage client
BlobServiceClient blobServiceClient2 = new BlobServiceClientBuilder()
.endpoint("https://<contract-storage-account>.blob.core.windows.net")
.credential(credentialStorage)
.buildClient();
String clientIdDatabases = System.getenv("Managed_Identity_Client_ID_Databases");
// Create a DefaultAzureCredential instance that configures the underlying
// ManagedIdentityCredential to use a user-assigned managed identity.
DefaultAzureCredential credentialDatabases = new DefaultAzureCredentialBuilder()
.managedIdentityClientId(clientIdDatabases)
.build()
// Create an Azure Cosmos DB client
CosmosClient cosmosClient = new CosmosClientBuilder()
.endpoint("https://<cosmos-db-account>.documents.azure.com:443/")
.credential(credentialDatabases)
.buildClient();
// Open a connection to Azure SQL using a managed identity.
// The DefaultAzureCredential instance stored in the credentialDatabases variable can't be
// used here, so sharing isn't possible between Cosmos DB and Azure SQL.
String connectionUrl = "jdbc:sqlserver://<azure-sql-hostname>.database.windows.net:1433;"
+ "database=<database-name>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database"
+ ".windows.net;loginTimeout=30;Authentication=ActiveDirectoryMSI;";
try {
Connection connection = DriverManager.getConnection(connectionUrl);
Statement statement = connection.createStatement();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
Spring Cloud Azure doesn't support configure multiple clients of the same service, the following code samples create multiple beans for this situation.
@Configuration
public class AzureStorageConfiguration {
@Bean("secondBlobServiceClient")
public BlobServiceClient secondBlobServiceClient(BlobServiceClientBuilder builder) {
return builder.endpoint("https://<receipt-storage-account>.blob.core.windows.net")
.buildClient();
}
@Bean("firstBlobServiceClient")
public BlobServiceClient firstBlobServiceClient(BlobServiceClientBuilder builder) {
return builder.buildClient();
}
}
from azure.cosmos import CosmosClient
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient
import os, pyodbc, struct
# Create a DefaultAzureCredential instance that configures the underlying
# ManagedIdentityCredential to use a user-assigned managed identity.
credential_storage = DefaultAzureCredential(
managed_identity_client_id=os.environ['Managed_Identity_Client_ID_Storage']
)
# First Blob Storage client
blob_service_client_1 = BlobServiceClient(
account_url="https://<receipt-storage-account>.blob.core.windows.net/",
credential=credential_storage
)
# Second Blob Storage client
blob_service_client_2 = BlobServiceClient(
account_url="https://<contract-storage-account>.blob.core.windows.net/",
credential=credential_storage
)
# Create a DefaultAzureCredential instance that configures the underlying
# ManagedIdentityCredential to use a user-assigned managed identity.
credential_databases = DefaultAzureCredential(
managed_identity_client_id=os.environ['Managed_Identity_Client_ID_Databases']
)
# Create an Azure Cosmos DB client
cosmos_client = CosmosClient(
os.environ['COSMOS_ENDPOINT'],
credential=credential_databases
)
# Connect to Azure SQL
token_bytes = credential_databases.get_token("https://database.windows.net/.default").token.encode("UTF-16-LE")
token_struct = struct.pack(f'<I{len(token_bytes)}s', len(token_bytes), token_bytes)
SQL_COPT_SS_ACCESS_TOKEN = 1256 # This connection option is defined by microsoft in msodbcsql.h
conn = pyodbc.connect(connection_string, attrs_before={SQL_COPT_SS_ACCESS_TOKEN: token_struct})
You can also associate a user-assigned managed identity and a system-assigned managed identity to a resource simultaneously. This can be useful in scenarios where all of the apps require access to the same shared services, but one of the apps also has a specific dependency on an additional service. Using a system-assigned managed identity also ensures that the identity tied to that specific app is deleted when the app is deleted, which can help keep your environment clean.
In this tutorial, you learned how to migrate an application to passwordless connections. Read the following resources to explore the concepts discussed in this article in more depth: