驗證對 Azure Batch 的要求
每個對批次服務所提出的要求必須經過驗證。 Batch 服務支援透過共用密鑰或 Microsoft Entra ID 進行驗證。
透過共用金鑰進行驗證
已驗證的要求需要兩個標頭: Date 或 ocp-date 標頭和 Authorization 標頭。 下列各節說明如何建構這些標頭。
指定日期標頭
所有經過驗證的要求都必須包含要求的國際標準時間 (UTC) 之時間戳記。 您可以在 ocp-date 標頭或標準 HTTP/HTTPS 日期 標頭中指定時間戳。 如果同時為要求指定這兩個標頭, 則會使用 ocp-date 的值做為要求的建立時間。
批次服務必須在要求建立後的 15 分鐘內收到要求。 如此一來,就能防止服務遭到安全性攻擊,例如重新執行攻擊。 提供 ocp-date 標頭是因為某些 HTTP 用戶端連結庫和 Proxy 會自動設定 Date 標頭,而且不會讓您有機會讀取其值,以便將其包含在已驗證的要求中。 如果您設定 ocp-date,請使用 Date 標頭的空白值來建構簽章。
指定授權標頭
已驗證的要求必須包含 授權 標頭。 若要驗證要求,您必須使用帳戶 (提出要求者) 的金鑰簽署要求,並以簽章做為要求的一部分傳遞。
Authorization 標頭的格式如下:
Authorization="SharedKey <AccountName>:<Signature>"
SharedKey
是授權配置的名稱,AccountName
要求資源的帳戶名稱,Signature
是雜湊式訊息驗證碼 (HMAC),此驗證碼從要求建構而來,並使用 SHA256 演算法計算,然後使用 Base64 編碼方式進行編碼。
下列各節說明如何建構 Authorization 標頭。
建構簽章字串
建構簽章字串時,請注意下列事項:
字串的 VERB 部分為 HTTP 動詞命令 (例如 GET 或 POST),且必須使用大寫。
簽章字串中包含的每個標頭只能出現一次。
所有標準 HTTP 標頭的值必須依照簽章格式中所示的順序加入字串,但不包括標頭名稱。 這些標頭若未指定為要求的一部分,則為空白,在此情況下,只有新行字元是必要項目。
當動詞命令是 POST 時,簽章字串中需要有 Content-Type 和 Content-Length 值做為要求標頭和值。 內容類型必須設定為 application/json;odata=minimalmetadata。
如果指定 ocp-date 標頭,則不需要 Date 標頭,只要為簽章字串的 Date 部分指定空行即可。 在此情況下,請遵循 建構標準標頭字串一 節中的指示,以新增 ocp-date 標頭。
在簽章字串中,所有顯示的新行字元 (\n) 都是必要項目。
如需如何建構組成簽章字串的
CanonicalizedHeaders
和CanonicalizedResource
字串的詳細資訊,請參閱本主題稍後的適當章節。
在對批次服務提出的要求上,若要將簽章字串編碼,請使用下列格式:
StringToSign = VERB + "\n" +
Content-Encoding + "\n"
Content-Language + "\n"
Content-Length + "\n"
Content-MD5 + "\n"
Content-Type + "\n" +
Date + "\n" +
If-Modified-Since + "\n"
If-Match + "\n"
If-None-Match + "\n"
If-Unmodified-Since + "\n"
Range + "\n"
CanonicalizedHeaders +
CanonicalizedResource;
下列範例顯示要求在 帳戶中列出作業 的簽章字串,逾時為 20 秒。 當標頭值不存在時,只會指定新行字元。
GET\n\n\n\n\n\n\n\n\n\n\n\nocp-date:Tue, 29 Jul 2014 21:49:13 GMT\n /myaccount/jobs\napi-version:2014-01-01.1.0\ntimeout:20
將此程式碼逐行細分會顯示相同字串的每個部分:
GET\n /*HTTP Verb*/
\n /*Content-Encoding*/
\n /*Content-Language*/
\n /*Content-Length*/
\n /*Content-MD5*/
\n /*Content-Type*/
\n /*Date*/
\n /*If-Modified-Since */
\n /*If-Match */
\n /*If-None-Match */
\n /*If-Unmodified-Since*/
\n /* Range */
ocp-date:Tue, 29 Jul 2014 21:49:13 GMT\n /*CanonicalizedHeaders*/
/myaccount/jobs\napi-version:2014-04-01.1.0\ntimeout:20 /*CanonicalizedResource*/
接下來,透過 UTF-8 編碼簽章字串使用 HMAC-SHA256 演演算法來編碼此字串、建構 Authorization 標頭,並將標頭新增至要求。 下列範例顯示相同作業的 Authorization 標頭:
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
建構正式的標頭字串
若要建構簽章字串的 CanonicalizedHeaders
部分,請遵循下列步驟:
擷取以 ocp-開頭之資源的所有標頭,包括 ocp-date 標頭。
將每個 HTTP 標頭名稱轉換成小寫。
以辭典編纂順序,依標頭名稱將標頭排序,採用遞增順序。 每個標頭在字串中只能出現一次。
請以單一空格取代任何斷裂空白。
修剪標頭中冒號兩旁的空格。
將新行字元附加至結果清單中的每個正式標頭。 將此清單中的所有標頭串連成單一字串,以建構
CanonicalizedHeaders
字串。
建構正式的資源字串
簽章字串的 CanonicalizedResource
部分代表所要求的批次服務資源。 從資源的 URI 衍生之 CanonicalizedResource
字串的任何部分,都應該與 URI 中編碼方式完全相同。
請注意下列建構正式資源字串的規則:
避免在查詢參數值中使用新行字元 (\n)。 如果必須使用,請確定不會影響正式資源字串的格式。
避免在查詢參數值中使用逗號。
您可以如下所示建構 CanonicalizedResource
字串:
開頭為斜線 ("/"),後面接著擁有要存取之資源的帳戶名稱。
附加資源的編碼 URI 路徑,不包括任何查詢參數。
擷取資源 URI 上的所有查詢參數,包括 api-version 參數。
將所有參數名稱轉換成小寫。
以辭典編纂順序,依參數名稱將查詢參數排序,採用遞增順序。
將每個查詢參數名稱和值進行 URL 解碼。
以下列格式將每個查詢參數名稱和值附加至字串,並確保名稱和值之間包含冒號 (:):
parameter-name:parameter-value
如果查詢參數包含多個值,請依辭典編纂順序將所有的值排序,然後將這些值加入逗號分隔清單中:
parameter-name:parameter-value-1,parameter-value-2,parameter-value-n
在每個名稱/值組之後附加新行字元 (\n)。
將簽章編碼
若要對簽章進行編碼,請對 UTF-8 編碼的簽章字串呼叫 HMAC-SHA256 演算法,並將結果編碼為 Base64。 請使用下列格式 (顯示為虛擬程式碼):
Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))
透過 Microsoft Entra ID 進行驗證
Azure Batch 支援使用 Microsoft Entra ID、Microsoft 的多租用戶雲端式目錄和身分識別管理服務進行驗證。 Azure 會使用 Microsoft Entra ID 來驗證自己的客戶、服務管理員和組織使用者。
注意
Microsoft Entra ID 驗證是選擇性的,但建議使用,只有在 Batch 帳戶設定為在使用者訂用帳戶中配置集區時才需要驗證。 當您建立新的 Batch 帳戶時,可以使用集區配置選項。 如果您的帳戶已設定為在 Batch 管理的訂用帳戶中配置集區,則使用 Microsoft Entra ID 進行驗證是選擇性的。 如需詳細資訊,請參閱 Batch – 虛擬機集區的 VNet 和自定義映像支援。
如需使用 Azure AD 驗證要求的一般資訊,請參閱 Azure REST API 參考。 若要搭配 Batch 服務使用 Azure AD,您需要下列端點。
Azure AD 端點「通用」端點為:
https://login.microsoftonline.com/common
Batch 服務的資源端點是︰
https://batch.core.windows.net/
如需向 Microsoft Entra ID 註冊 Batch 應用程式的其他資訊,請參閱使用 Microsoft Entra ID 驗證 Azure Batch 服務。