於本機開發期間用服務主體向 Azure 服務驗證 NET 應用程式
建立雲端應用程式時,開發人員必須在本機工作站上偵錯及測試應用程式。 當應用程式在本機開發期間於開發人員的工作站上執行時,仍必須向應用程式使用的任何 Azure 服務進行驗證。 本文說明如何設定在本機開發期間要使用的專用應用程式服務主體物件。
本機開發專用的應用程式服務主體可讓您遵循應用程式開發期間最低權限的準則。 由於權限的範圍會限定為開發期間應用程式所需的內容,因此應用程式之程式碼無法意外存取要供不同應用程式使用的 Azure 資源。 這也可防止應用程式在移至生產環境時發生錯誤,因為應用程式在開發環境中擁有較多權限。
在 Azure 中註冊應用程式時,會為應用程式設定應用程式服務主體。 為本機開發註冊應用程式時,建議您:
- 為每個在應用程式上作業的開發人員建立個別的應用程式註冊。 這麼做會建立不同的應用程式服務主體,供開發人員於本機開發期間使用,且能避免開發人員針對單一應用程式服務主體共用認證。
- 為每個應用程式建立個別的應用程式註冊。 這麼做會限制應用程式的權限,使之僅具備所需的權限。
在本機開發期間,會使用應用程式服務主體的身分識別來設定環境變數。 Azure SDK for NET 會讀取這些環境變數,並使用這項資訊向所需的 Azure 資源驗證應用程式。
1:在 Azure 中註冊應用程式
系統會用於 Azure 註冊的應用程式建立應用程式服務主體物件。 這可透過 Azure 入口網站或 Azure CLI 來完成。
登入 Azure 入口網站並遵循下列步驟。
2:為本機開發建立 Azure AD 安全性群組
由於處理應用程式的開發人員通常有許多位,建議您在本機開發中建立 Azure AD 群組來封裝應用程式所需的一切角色 (權限),而非將角色指派給個別的服務主體物件。 這具有以下優點。
- 由於角色是在群組層級指派,因此指派給每位開發人員的角色都能保證相同。
- 如果應用程式需要新角色,只需從應用程式的 Azure AD 群組加以新增。
- 如有新開發人員加入小組,則系統會為其建立新的應用程式服務主體並新增至群組,確定開發人員具備處理應用程式的適當權限。
3:為應用程式指派角色
接著,您必須決定應用程式針對哪些資源需要哪些角色 (權限),並將這些角色指派給應用程式。 在此範例中,角色會指派給步驟 2 建立的 Azure Active Directory 群組。 角色可在資源、資源群組或訂閱範圍內獲派其他角色。 此範例顯示如何在資源群組範圍內指派角色,因為多數應用程式都會將所有 Azure 資源劃分在單一資源群組中。
4:設定應用程式環境變數
DefaultAzureCredential
物件會於執行階段在一組環境變數中尋找服務主體的資訊。 使用 .NET 時設定環境變數的方法有很多,視您使用的工具和環境而定。
無論您選擇哪一種方法,都需要在使用服務主體時設定下列環境變數。
AZURE_CLIENT_ID
→ 應用程式識別碼的值。AZURE_TENANT_ID
→ 租用戶識別碼的值。AZURE_CLIENT_SECRET
→ 為應用程式產生的密碼/認證。
在本機使用 Visual Studio 時,可在專案 Properties
資料夾的 launchsettings.json
檔案內設定環境變數。 應用程式啟動時,系統會自動提取這些值。 請注意,這些設定不會在您部署應用程式時跟著移動,因此您仍須在目標裝載環境中設定環境變數。
"profiles": {
"SampleProject": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "https://localhost:7177;http://localhost:5177",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
"AZURE_TENANT_ID":"11111111-1111-1111-1111-111111111111",
"AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
}
},
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
"AZURE_TENANT_ID": "11111111-1111-1111-1111-111111111111",
"AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
}
}
}
5:在應用程式中實作 DefaultAzureCredential
DefaultAzureCredential
支援多種驗證方法,並會決定執行階段期間使用的驗證方法。 因此,您的應用程式可在相異的環境中使用不同的驗證方法,無須實作環境特定程式碼。
DefaultAzureCredential
尋找認證的順序和位置,可在 DefaultAzureCredential中找到。
為實作 DefaultAzureCredential
,請先將 Azure.Identity
與選擇性的 Microsoft.Extensions.Azure
套件新增至您的應用程式。 您可透過命令列或 NuGet 套件管理員執行此動作。
在應用程式專案目錄中開啟您想要的終端環境,然後輸入下列命令。
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Azure 服務通常使用 SDK 的對應用戶端類別來存取。 這些類別和您自訂的服務都應在 Program.cs
檔案中註冊,使其可在應用程式中透過相依性插入來存取。 請依照下列步驟,在 Program.cs
內正確設定您的服務和 DefaultAzureCredential
。
Azure.Identity
使用指示詞包含using
和Microsoft.Extensions.Azure
命名空間。- 用相關的協助程式方法註冊 Azure 服務。
- 將
DefaultAzureCredential
物件的執行個體傳遞至UseCredential
方法。
下列程式碼區段示範其中一種範例。
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
或者,您也可以更直接地在服務中使用 DefaultAzureCredential
,而不求助於其他 Azure 註冊方法,如下所示。
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
上述程式碼在本機開發期間於本機工作站上執行時,會尋找環境變數中的應用程式服務主體,或在 Visual Studio、VS Code、Azure CLI 或 Azure PowerShell 中尋找一組開發人員認證;任意者皆可於本機開發期間用來向 Azure 資源驗證應用程式。
部署至 Azure 時,這同一組程式碼也可向其他 Azure 資源驗證您的應用程式。 DefaultAzureCredential
可擷取環境設定與受控識別設定,以便自動向其他服務進行驗證。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應