Authentication

DefaultAzureCredential

The DefaultAzureCredential is appropriate for most scenarios where the application is intended to ultimately be run in the Azure Cloud. This is because the DefaultAzureCredential combines credentials commonly used to authenticate when deployed, with credentials used to authenticate in a development environment.

DefaultAzureCredential is intended to simplify getting started with the SDK by handling common scenarios with reasonable default behaviors. Developers who want more control or whose scenario isn’t served by the default settings should use other credential types.

The DefaultAzureCredential will attempt to authenticate via the following mechanisms in order.

Environment - The DefaultAzureCredential will read account information specified via environment variables and use it to authenticate.
Managed Identity - If the application is deployed to an Azure host with Managed Identity enabled, the DefaultAzureCredential will authenticate with that account.
IntelliJ - If the developer has authenticated via Azure Toolkit for IntelliJ, the DefaultAzureCredential will authenticate with that account.
Visual Studio Code - If the developer has authenticated via the Visual Studio Code Azure Account plugin, the DefaultAzureCredential will authenticate with that account.
Azure CLI - If the developer has authenticated an account via the Azure CLI az login command, the DefaultAzureCredential will authenticate with that account.

There could be some ERROR logs be printed out while the DefaultAzureCredential running the chain and trying to find the first available credential.It doesn’t mean the DefaultAzureCredential is broken or unavailable.Meanwhile, we’ll keep improving this logging experience.

Please refer to Authorize access with Azure AD to make sure the security principal has been granted the sufficient permission to access the Azure resource.

Managed Identity

A common challenge for developers is the management of secrets and credentials used to secure communication between different components making up a solution. Managed identities eliminate the need for developers to manage credentials. Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens. For example, an application may use a managed identity to access resources like Azure Key Vault where developers can store credentials in a secure manner or to access storage accounts.

We encourage using manged identity instead of using connection string or key in your application for it’s more secure and will save the trouble of managing secrets and credentials. In this case, DefaultAzureCredential could better serve the scenario of developing locally using account information stored locally and deploying the application to Azure Cloud and using Manged Identity.

Managed Identity Types

There are two types of managed identities:

System-assigned Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity an identity is created in Azure AD that is tied to the lifecycle of that service instance. So when the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
User-assigned You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. In the case of user-assigned managed identities, the identity is managed separately from the resources that use it.

When a user-assigned managed identity is used, you can specify it by spring.cloud.azure.credential.managed-identity-client-id or spring.cloud.azure.<azure-service>.credential.managed-identity-client-id. No credential configuration is needed if a system-assigned managed identity is used.

Please refer to Authorize access with Azure AD to make sure the security principal has been granted the sufficient permission to access the Azure resource.

Please refer to What are managed identities for Azure resources? for more details about manged identity.

Other Credential Types

Developers who want more control or whose scenario isn’t served by the DefaultAzureCredential or whose scenario isn’t served by the default settings should use other credential types.

Authentication and authorization with Azure Active Directory

With Azure AD, you can use Azure role-based access control (Azure RBAC) to grant permissions to a security principal, which may be a user, or an application service principal. When a security principal (a user, or an application) attempts to access an Azure resource, for example an Event Hubs resource, the request must be authorized. With Azure AD, access to a resource is a two-step process.

First, the security principal’s identity is authenticated, and an OAuth 2.0 token is returned.
Next, the token is passed as part of a request to the Azure service to authorize access to the specified resource.

Authenticate with Azure Active Directory

For applications want to connect to resources that support Azure Active Directory (Azure AD) authentication, below configurations could be set with prefix spring.cloud.azure.credential or spring.cloud.azure.<azure-service>.credential

Table 1. Authentication properties
Property	Description
client-id	Client id to use when performing service principal authentication with Azure.
client-secret	Client secret to use when performing service principal authentication with Azure.
client-certificate-path	Client secret to use when performing service principal authentication with Azure.
client-certificate-password	Password of the certificate file.
username	Username to use when performing username/password authentication with Azure.
password	Password to use when performing username/password authentication with Azure.
managed-identity-client-id	Client id to use when using user-assigned managed identity or app registration (when working with AKS pod-identity) to authenticate with Azure.

To see the list of all Spring Cloud Azure related configuration properties please check the Appendix page.

Authorize access with Azure Active Directory

The authorization step requires that one or more Azure roles be assigned to the security principal. The roles that are assigned to a security principal determine the permissions that the principal will have.

To see the list of all Azure built-in roles please check Azure built-in roles.

Following are the Azure built-in roles for authorizing access to Azure services supported in Spring Cloud Azure:

Table 2. Azure built-in roles
Role	Description
App Configuration Data Owner	Allows full access to App Configuration data.
App Configuration Data Reader	Allows read access to App Configuration data.
Azure Event Hubs Data Owner	Allows for full access to Azure Event Hubs resources.
Azure Event Hubs Data Receiver	Allows receive access to Azure Event Hubs resources.
Azure Event Hubs Data Sender	Allows send access to Azure Event Hubs resources.
Azure Service Bus Data Owner	Allows for full access to Azure Service Bus resources.
Azure Service Bus Data Receiver	Allows for receive access to Azure Service Bus resources.
Azure Service Bus Data Sender	Allows for send access to Azure Service Bus resources.
Storage Blob Data Owner	Provides full access to Azure Storage blob containers and data, including assigning POSIX access control.
Storage Blob Data Reader	Read and list Azure Storage containers and blobs.
Storage Queue Data Reader	Read and list Azure Storage queues and queue messages.
Redis Cache Contributor	Manage Redis caches.

When using Spring Cloud Azure Resource Manager to get the connection strings of Event Hubs, Service Bus, and Storage Queue, or properties of Cache for Redis, assign the Azure built-in role Contributor. Azure Cache for Redis is special, and you can also assign the Redis Cache Contributor role to get the Redis properties.

A Key Vault access policy determines whether a given security principal, namely a user, application or user group, can perform different operations on Key Vault secrets, keys, and certificates. You can assign access policies using the Azure portal, the Azure CLI, or Azure PowerShell. Check here for more details.

Azure Cosmos DB exposes 2 built-in role definitions: Cosmos DB Built-in Data Reader and Cosmos DB Built-in Data Contributor. However, Azure portal support for role management is not available yet. Check here for more details about the permission model, role definitions, and role assignment.

SAS Token

It’s also configurable for services support authenticating with Shared Access Signature (SAS). spring.cloud.azure.<azure-service>.sas-token is the property to configure. For example, using spring.cloud.azure.storage.blob.sas-token to authenticate to Storage Blob service.

Connection String

Connection string are supported by some Azure services to provide connection information as well as credentials. To connect to those Azure services using connection string, just configure spring.cloud.azure.<azure-service>.connection-string will do. For example, spring.cloud.azure.eventhubs.connection-string to connect to Event Hubs service.