Azure Batchに対する要求の認証
Batch Service に対して行われたすべての要求を認証する必要があります。 Batch サービスでは、共有キーまたはMicrosoft Entra IDを使用した認証がサポートされます。
共有キーを使用した認証
認証された要求には、 Date ヘッダーまたは ocp-date ヘッダーと Authorization ヘッダーの 2 つのヘッダーが必要です。 以下のセクションでは、これらのヘッダーの作成方法について説明します。
Date ヘッダーの指定
すべての認証された要求には、要求の世界協定時刻 (UTC) タイムスタンプが含まれる必要があります。 タイムスタンプは 、ocp-date ヘッダーまたは標準 HTTP/HTTPS 日付 ヘッダーで指定できます。 要求に両方のヘッダーが指定されている場合は、 ocp-date の値が要求の作成時刻として使用されます。
Batch Service は、作成から 15 分以内に要求を受け取る必要があります。 それにより、再生攻撃などのセキュリティ攻撃からサービスを保護します。 ocp-date ヘッダーは、一部の HTTP クライアント ライブラリとプロキシによって Date ヘッダーが自動的に設定され、認証された要求に含めるために値を読み取る機会がないために提供されます。 ocp-date を設定する場合は、Date ヘッダーの空の値を使用して署名を作成します。
Authorization ヘッダーの指定
認証された要求には 、Authorization ヘッダーを含める必要があります。 要求を認証するには、要求を行うアカウントのキーで要求に署名し、その署名を要求の一部として渡す必要があります。
Authorization ヘッダーの形式は次のとおりです。
Authorization="SharedKey <AccountName>:<Signature>"
SharedKey
は、認証スキームの名前です。AccountName
は、リソースを要求しているアカウントの名前です。Signature
は、要求から作成され、SHA256 アルゴリズムを使用して計算された後、Base64 エンコーディングを使用してエンコードされた、Hash-based Message Authentication Code (HMAC) です。
次のセクションでは、 Authorization ヘッダーを構築する方法について説明します。
署名文字列の作成
署名文字列を作成するときは、以下の点に注意してください。
文字列の VERB 部分は、GET や POST などの HTTP 動詞であり、大文字を使用する必要があります。
署名文字列には各ヘッダーが 1 回だけ出現できます。
すべての標準 HTTP ヘッダーの値は、署名形式において示されている順序で文字列に含まれる必要があります (ヘッダー名は含まれません)。 これらのヘッダーは、要求の一部として指定されていない場合は空にできます。その場合は、改行文字だけが必要です。
動詞が POST の場合、要求ヘッダーおよび署名文字列内の値として Content-Type および Content-Length の値が必要です。 Content-Type は application/json に設定する必要があります 。odata=minimalmetadata。
ocp-date ヘッダーが指定されている場合、Date ヘッダーは必要ありません。署名文字列の Date 部分に空の行を指定するだけです。 この場合は、ocp-date ヘッダーを追加するための正規化されたヘッダー文字列の構築に関するセクションの手順に従います。
示されているすべての改行文字 (\n) は署名文字列に必要です。
署名文字列を構成する
CanonicalizedHeaders
およびCanonicalizedResource
文字列の作成の詳細については、後の該当するセクションを参照してください。
Batch Service に対する要求の署名文字列をエンコードするには、次の形式を使用します。
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
同じ文字列の各部分を 1 行ごとに分解すると次のようになります。
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-date ヘッダーを含め、ocp-で始まるリソースのすべてのヘッダーを取得します。
各 HTTP ヘッダー名を小文字に変換します。
ヘッダーをヘッダー名のアルファベット順に並べ替えます。 各ヘッダーは文字列内に 1 回だけ出現できます。
改行空白文字は 1 つのスペースに置き換えます。
ヘッダーのコロンの前後にある空白文字を除去します。
結果のリストの各正規化されたヘッダーに改行文字を追加します。 このリストのすべてのヘッダーを 1 つの文字列に連結することで、
CanonicalizedHeaders
文字列を作成します。
正規化リソース文字列の作成
署名文字列の CanonicalizedResource
部分は、要求の対象である Batch Service のリソースを表します。 リソースの URI から抽出される CanonicalizedResource
文字列のすべての部分は、URI の場合と同じように正確にエンコードする必要があります。
正規化されたリソース文字列の作成では、次の規則に留意してください。
クエリ パラメーターの値では改行文字 (\n) を使用しないようにします。 使用する必要がある場合は、正規化されたリソース文字列の形式に影響がないことを確認します。
クエリ パラメーターの値ではコンマを使用しないようにします。
次のように、CanonicalizedResource
文字列を作成できます。
先頭はスラッシュ ("/") で、その後にアクセス対象のリソースを所有しているアカウントの名前を追加します。
リソースのエンコードされた URI パスを追加します。クエリ パラメーターは指定しません。
api-version パラメーターを含め、リソース URI のすべてのクエリ パラメーターを取得します。
すべてのパラメーター名を小文字に変換します。
クエリ パラメーターをパラメーター名のアルファベット順に並べ替えます。
各クエリ パラメーターの名前と値を 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 のマルチテナント クラウド ベースのディレクトリと ID 管理サービスである Microsoft Entra ID を使用した認証がサポートされています。 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/
Batch アプリケーションをMicrosoft Entra IDに登録する方法の詳細については、「Microsoft Entra IDを使用してAzure Batch サービスを認証する」を参照してください。