於本機開發期間使用服務主體向 Azure 服務驗證 .NET 應用程式
開發人員必須在本機工作站上偵錯及測試雲端應用程式。 當應用程式在本機開發期間於開發人員的工作站上執行時,仍必須向應用程式使用的任何 Azure 服務進行驗證。 本文說明如何設定在本機開發期間要使用的專用應用程式服務主體物件。
本機開發專用的應用程式服務主體可讓您遵循應用程式開發期間最低權限的準則。 由於權限的範圍會限定為開發期間應用程式所需的內容,因此應用程式程式碼無法意外存取要供不同應用程式使用的 Azure 資源。 這也可防止應用程式在移至生產環境時發生錯誤,因為應用程式在開發環境中擁有較多權限。
在 Azure 中註冊應用程式時,會為應用程式設定應用程式服務主體。 為本機開發註冊應用程式時,建議您:
- 為每個在應用程式上作業的開發人員建立個別的應用程式註冊。 這麼做會建立不同的應用程式服務主體,供開發人員於本機開發期間使用,且能避免開發人員針對單一應用程式服務主體共用認證。
- 為每個應用程式建立個別的應用程式註冊。 這麼做會限制應用程式的權限,使之僅具備所需的權限。
在本機開發期間,會使用應用程式服務主體的身分識別來設定環境變數。 Azure 身分識別會讀取這些環境變數,並使用這項資訊向所需的 Azure 資源驗證應用程式。
1:在 Azure 中註冊應用程式
系統會用於 Azure 註冊的應用程式建立應用程式服務主體物件。 這可透過 Azure 入口網站或 Azure CLI 來完成。
登入 Azure 入口網站並遵循下列步驟。
2 - 建立 Microsoft Entra 群組以進行本機開發
由於處理應用程式的開發人員通常有許多位,建議您在本機開發中建立 Microsoft Entra 群組來封裝應用程式所需的一切角色 (權限),而非將角色指派給個別的服務主體物件。 這些方法提供下列優點:
- 由於角色是在群組層級指派,因此指派給每位開發人員的角色都能保證相同。
- 如果應用程式需要新角色,只要在應用程式的群組新增即可。
- 如有新開發人員加入小組,則系統會為其建立新的應用程式服務主體並新增至群組,確定開發人員具備處理應用程式的適當權限。
3:為應用程式指派角色
接著,請決定應用程式針對哪些資源需要哪些角色 (權限),並將這些角色指派給應用程式。 在此範例中,角色會指派給步驟 2 建立的 Microsoft Entra 群組。 群組可在資源、資源群組或訂閱範圍內獲派其他角色。 此範例會顯示如何在資源群組範圍內指派角色,因為多數應用程式都會將所有 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 是向 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
可擷取環境設定與受控識別設定,以便自動向其他服務進行驗證。