从本地托管的 .NET 应用向 Azure 资源进行身份验证
在 Azure 外部(例如本地或第三方数据中心)托管的应用在访问 Azure 资源时应使用应用程序服务主体向 Azure 进行身份验证。 应用程序服务主体对象是使用 Azure 中的应用注册过程创建的。 创建应用程序服务主体时,将为应用生成客户端 ID 和客户端机密。 然后客户端 ID、客户端密码和租户 ID 将存储在环境变量中,以便在运行时 Azure 标识库可使用它们来对访问 Azure 的应用进行身份验证。
应为托管应用的每个环境创建不同的应用注册。 这样,就可以为每个服务主体配置特定于环境的资源权限,并确保部署到一个环境的应用不会与另一个环境中的 Azure 资源通信。
1 - 在 Azure 中注册应用程序
可以使用 Azure 门户或 Azure CLI 向 Azure 注册应用。
登录到 Azure 门户并执行以下步骤。
2 - 将角色分配到应用程序服务主体
接下来,需要确定应用在哪些资源上需要哪些角色(权限),并将这些角色分配到应用。 可以在资源、资源组或订阅范围分配角色。 此示例演示如何在资源组范围为服务主体分配角色,因为大多数应用将其所有 Azure 资源分组到单个资源组中。
3 - 为应用程序配置环境变量
在运行时,DefaultAzureCredential
对象将在一组环境变量中查找服务主体凭据。 使用 .NET 时,可以根据你的工具和环境以多种方式配置环境变量。
无论选择哪种方法,都请在处理服务主体时配置以下环境变量:
AZURE_CLIENT_ID
→ 应用 ID 值。AZURE_TENANT_ID
→ 租户 ID 值。AZURE_CLIENT_SECRET
→ 为应用生成的密码/凭据。
如果应用托管在 IIS 中,建议为每个应用池设置环境变量,以隔离应用之间的设置。
appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='Contoso'].environmentVariables.[name='ASPNETCORE_ENVIRONMENT',value='Production']" /commit:apphost
appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='Contoso'].environmentVariables.[name='AZURE_CLIENT_ID',value='00000000-0000-0000-0000-000000000000']" /commit:apphost
appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='Contoso'].environmentVariables.[name='AZURE_TENANT_ID',value='11111111-1111-1111-1111-111111111111']" /commit:apphost
appcmd.exe set config -section:system.applicationHost/applicationPools /+"[name='Contoso'].environmentVariables.[name='AZURE_CLIENT_SECRET',value='=abcdefghijklmnopqrstuvwxyz']" /commit:apphost
还可以在 applicationHost.config
文件中使用 applicationPools
元素直接配置这些设置:
<applicationPools>
<add name="CorePool" managedRuntimeVersion="v4.0" managedPipelineMode="Classic">
<environmentVariables>
<add name="ASPNETCORE_ENVIRONMENT" value="Development" />
<add name="AZURE_CLIENT_ID" value="00000000-0000-0000-0000-000000000000" />
<add name="AZURE_TENANT_ID" value="11111111-1111-1111-1111-111111111111" />
<add name="AZURE_CLIENT_SECRET" value="=abcdefghijklmnopqrstuvwxyz" />
</environmentVariables>
</add>
</applicationPools>
4 - 在应用程序中实现 DefaultAzureCredential
DefaultAzureCredential 是一个带个人观点的有序机制序列,用于向 Microsoft Entra 进行身份验证。 每个身份验证机制都是一个派生自 TokenCredential 类的类,称为“凭据”。 在运行时,DefaultAzureCredential
尝试使用第一个凭据进行身份验证。 如果该凭据无法获取访问令牌,则会尝试序列中的下一个凭据,以此类推,直到成功获取访问令牌。 这样,应用就可在不同的环境中使用不同的凭据,而无需编写特定于环境的代码。
DefaultAzureCredential
按哪种顺序和在哪个位置查找凭据见于 DefaultAzureCredential。
若要使用 DefaultAzureCredential
,请将 Azure.Identity 和 Microsoft.Extensions.Azure 包添加到应用程序:
在所选终端中,导航到应用程序项目目录并运行以下命令:
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
使用各种 Azure SDK 客户端库中的专用客户端类访问 Azure 服务。 应注册这些类和你自己的自定义服务,以便可以在整个应用中通过依赖项注入来访问它们。 在 Program.cs
中,完成以下步骤以注册客户端类和 DefaultAzureCredential
:
- 通过
using
指令包含Azure.Identity
和Microsoft.Extensions.Azure
命名空间。 - 使用相应的
Add
前缀扩展方法注册 Azure 服务客户端。 - 将
DefaultAzureCredential
的实例传递给UseCredential
方法。
例如:
using Microsoft.Extensions.Azure;
using Azure.Identity;
builder.Services.AddAzureClients(clientBuilder =>
{
clientBuilder.AddBlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"));
clientBuilder.UseCredential(new DefaultAzureCredential());
});
UseCredential
的替代方法是直接实例化 DefaultAzureCredential
:
using Azure.Identity;
builder.Services.AddSingleton<BlobServiceClient>(_ =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
上述代码在本地开发工作站上运行时,它会在应用程序服务主体的环境变量或本地安装的开发人员工具(如 Visual Studio)中查找一组开发人员凭据。 在本地开发期间,两种方法都可用于对访问 Azure 资源的应用进行身份验证。
部署到 Azure 时,此代码也可以对访问 Azure 资源的应用进行身份验证。 DefaultAzureCredential
可以检索环境设置和托管标识配置,以自动向其他服务进行身份验证。