你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

对Azure Batch的请求进行身份验证

  • 项目

针对批处理服务发出的每个请求都必须经过身份验证。 Batch 服务支持通过共享密钥或Microsoft Entra ID进行身份验证。

通过共享密钥进行身份验证

经过身份验证的请求需要两个标头： Date 或 ocp-date 标头和 Authorization 标头。 以下几节介绍如何构造这些标头。

指定日期标头

所有接受身份验证的请求都必须包括请求的协调世界时 (UTC) 时间戳。 可以在 ocp-date 标头或标准 HTTP/HTTPS Date 标头中指定时间戳。 如果为请求指定了两个标头，则 ocp-date 的值将用作请求的创建时间。

批处理服务必须在创建后的 15 分钟内接收请求。 通过执行此操作，服务能够防范某些安全攻击，例如重放攻击。 之所以提供 ocp-date 标头，是因为某些 HTTP 客户端库和代理会自动设置 Date 标头，并且你没有机会读取其值以将其包含在经过身份验证的请求中。 如果设置 ocp-date，请使用 Date 标头的空值构造签名。

指定授权标头

经过身份验证的请求必须包含 Authorization 标头。 要对请求进行身份验证，必须用提出请求的帐户的密钥来签署请求，并将签名包含在请求中进行传递。

Authorization 标头的格式如下所示：

Authorization="SharedKey <AccountName>:<Signature>"

SharedKey 是授权方案的名称，AccountName 是请求资源的帐户的名称，Signature 是基于散列的消息身份验证代码 (HMAC)，该代码基于请求构造，并使用 SHA256 算法计算，然后使用 Base64 编码方式进行编码。

以下部分介绍如何构造 Authorization 标头。

构造签名字符串

构造签名字符串时，请注意以下几点：

  • 字符串的 VERB 部分是 HTTP 动词，如 GET 或 POST，必须为大写形式。

  • 包括在签名字符串中的每个标头都只能出现一次。

  • 所有标准 HTTP 标头的值都必须按照签名格式中所示顺序包括在字符串中，且不含头名称。 如果这些标头未指定为请求的一部分，则可能为空；在这种情况下，只需要换行符。

  • 当谓词为 POST 时，需要使用 Content-Type 和 Content-Length 值作为签名字符串中的请求标头和值。 Content-Type 必须设置为 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 部分，请执行以下步骤：

  1. 检索以 ocp-开头的资源的所有标头，包括 ocp-date 标头。

  2. 将每个 HTTP 标头名称转换为小写形式。

  3. 以升序基于标头名称按字母顺序对标头进行排序。 每个标头在字符串中只出现一次。

  4. 用一个空格替换所有换行空格。

  5. 修剪标头中冒号旁边的空格。

  6. 在产生的列表中的每一个规范化标头之后追加一个换行符。 将此列表中的所有标头连接起来成为一个字符串，构造 CanonicalizedHeaders 字符串。

构造规范化资源字符串

签名字符串的 CanonicalizedResource 部分表示要请求的批处理服务资源。 派生自资源 URI 的 CanonicalizedResource 字符串的任何部分都应该完全按照其在 URI 中的形式进行编码。

记住以下规则以构造规范化资源字符串：

  • 避免在查询参数的值中使用换行符 (\n)。 如果必须使用换行符，请确保它不会影响规范化资源字符串的格式。

  • 避免在查询参数值中使用逗号。

可以按如下所述构造 CanonicalizedResource 字符串：

  1. 以正斜杠（“/”)开头，后接拥有待访问资源的帐户的名称。

  2. 不带任何查询参数，附加该资源的编码 URI 路径。

  3. 检索资源 URI 上的所有查询参数，包括 api-version 参数。

  4. 将所有参数名称转换为小写形式。

  5. 以升序基于参数名称按字母顺序对查询参数进行排序。

  6. 对每个查询参数名称和值进行 URL 解码。

  7. 按以下格式在该字符串之后附加每个查询参数名称和值，并确保在名称与值之间使用冒号 (:)：

    parameter-name:parameter-value

  8. 如果一个查询参数具有多个值，请按字母顺序将所有值进行排序，然后以逗号分隔列表的形式包括这些值：

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

  9. 在每个名称/值对之后附加换行符 (\n)。

对签名进行编码

要对签名进行编码，请对 UTF-8 编码的签名字符串调用 HMAC-SHA256 算法，并将结果编码为 Base64 格式。 使用以下格式（显示为伪代码）：

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

通过 Microsoft Entra ID 进行身份验证

Azure Batch 支持使用 Microsoft 基于云的多租户目录和标识管理服务 Microsoft Entra ID 进行身份验证。 Azure 使用Microsoft Entra ID对自己的客户、服务管理员和组织用户进行身份验证。

注意

使用 Microsoft Entra ID 进行身份验证是可选的，但建议这样做，仅当 Batch 帐户设置为在用户订阅中分配池时，才需要身份验证。 创建新的 Batch 帐户时，池分配选项可用。 如果帐户设置为在 Batch 管理的订阅中分配池，则使用 Microsoft Entra ID 进行身份验证是可选的。 有关详细信息，请参阅 Batch - VNet 和虚拟机池的自定义映像支持。

有关使用 Azure AD 对请求进行身份验证的一般信息，请参阅 Azure REST API 参考。 若要将 Azure AD 与 Batch 服务配合使用，需要以下终结点。

Azure AD 终结点“通用”终结点为：

https://login.microsoftonline.com/common

批处理服务的资源终结点为：

https://batch.core.windows.net/

有关向 Microsoft Entra ID 注册 Batch 应用程序的其他信息，请参阅使用 Microsoft Entra ID 对Azure Batch服务进行身份验证。