Проверка подлинности запросов к пакетная служба Azure

  • Статья

Каждый запрос к службе Batch должен пройти проверку подлинности. Пакетная служба поддерживает проверку подлинности с помощью общего ключа или Microsoft Entra ID.

Проверка подлинности с помощью общего ключа

Для запроса, прошедшего проверку подлинности, требуется два заголовка: заголовок Date или ocp-date и заголовок Authorization . Следующие шаги описывают процесс создания этих заголовков.

Указание заголовка даты

Все запросы с проверкой подлинности должны включать отметку времени в формате UTC. Метку времени можно указать в заголовке ocp-date или в стандартном заголовке даты HTTP/HTTPS. Если для запроса указаны оба заголовка, в качестве времени создания запроса используется значение ocp-date .

Служба Batch должна получить запрос в течение 15 минут после его создания. В этом случае служба будет защищена от атак на систему безопасности, таких как атаки воспроизведения. Заголовок ocp-date предоставляется, так как некоторые клиентские библиотеки и прокси-серверы HTTP автоматически задают заголовок Date и не дают возможности прочитать его значение, чтобы включить его в запрос, прошедший проверку подлинности. Если вы задали ocp-date, создайте сигнатуру с пустым значением для заголовка Date .

Указание заголовка авторизации

Запрос, прошедший проверку подлинности, должен содержать заголовок авторизации . Для проверки подлинности запроса необходимо подписать запрос ключом учетной записи, которая выполняет запрос, и передать подпись в составе запроса.

Формат заголовка авторизации выглядит следующим образом:

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

где SharedKey — название схемы авторизации, AccountName — имя учетной записи, запрашивающей ресурс, а Signature — код проверки подлинности на основе хэша (HMAC), построенный из запроса и вычисленный с помощью алгоритма SHA256, а затем закодированный в Base64.

В следующих разделах описывается создание заголовка Authorization .

Построение строки подписи

При создании строки подписи помните о следующем.

  • Часть VERB строки — это HTTP-команда, например GET или PUT, и она должна быть написана прописными буквами.

  • Каждый заголовок, включенный в строку подписи, может отображаться только один раз.

  • Значения всех стандартных заголовков HTTP необходимо включить в строку в порядке, показанном в формате подписи, без имен заголовков. Эти заголовки могут быть пустыми, если они не указаны как часть запроса; в таком случае требуется только символ новой линии.

  • Если используется команда POST, в качестве заголовков запроса и значений в строке подписи требуется указать значения параметров Content-Type и Content-Length. Content-Type должен иметь значение application/json; odata=minimalmetadata.

  • Если указан заголовок ocp-date , то заголовок Date не требуется. Просто укажите пустую строку для части Date строки подписи. В этом случае следуйте инструкциям в разделе Создание строки канонических заголовков , чтобы добавить заголовок ocp-date .

  • Все показанные символы новой линии (\n) необходимы в строке подписи.

  • Подробные сведения о построении строк CanonicalizedHeaders и CanonicalizedResource, которые являются частью строки подписи, см. в соответствующих подразделах ниже.

Для кодирования строки подписи для запроса к службе Batch используйте следующий формат:

  
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*/

Затем закодируйте эту строку с помощью алгоритма HMAC-SHA256 для строки подписи в кодировке UTF-8, создайте заголовок Authorization и добавьте заголовок в запрос. В следующем примере показан заголовок Authorization для той же операции:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Построение канонических строк заголовков

Чтобы построить часть CanonicalizedHeaders строки подписи, выполните следующие действия.

  1. Получение всех заголовков ресурса, которые начинаются с ocp-, включая заголовок ocp-date .

  2. Преобразуйте все имена заголовков HTTP к нижнему регистру.

  3. Лексикографически отсортируйте заголовки по имени в порядке возрастания. Каждый заголовок может появляться в строке только один раз.

  4. Замените разрывные пробелы одинарным интервалом.

  5. Усеките все пробелы вокруг двоеточия в заголовке.

  6. Добавьте символ новой линии к каждому каноническому заголовку в полученном списке. Постройте строку CanonicalizedHeaders, объединив все заголовки в этом списке в одну строку.

Построение канонической строки ресурса

Часть строки подписи CanonicalizedResource представляет ресурс службы Batch, который является целевым для запроса. Любая часть строки CanonicalizedResource, выведенная из URI ресурса, должна быть кодирована точно так же, как в 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) после каждой пары «имя-значение».

Кодирование сигнатуры

Для кодирования сигнатуры вызовите алгоритм HMAC-SHA256 для строки сигнатуры в кодировке UTF-8 и закодируйте результат в Base64. Используйте следующий формат (показан как псевдокод):

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

Проверка подлинности через Microsoft Entra ID

пакетная служба Azure поддерживает проверку подлинности с помощью Microsoft Entra ID, мультитенантного облачного каталога и службы управления удостоверениями Майкрософт. Azure использует Microsoft Entra ID для проверки подлинности собственных клиентов, администраторов служб и пользователей организации.

Примечание

Проверка подлинности с помощью Microsoft Entra ID необязательна, но рекомендуется. Она требуется только в том случае, если учетная запись пакетной службы настроена для выделения пулов в пользовательской подписке. Параметр выделения пула доступен при создании учетной записи пакетной службы. Если ваша учетная запись настроена для выделения пулов в подписке, управляемой пакетной службой, использование Microsoft Entra ID для проверки подлинности является необязательным. Дополнительные сведения см. в статье Пакетная служба — поддержка виртуальных сетей и пользовательских образов для пулов виртуальных машин.

Общие сведения о проверке подлинности запроса с помощью Azure AD см. в справочнике по REST API Azure. Чтобы использовать Azure AD с пакетной службой, вам потребуются следующие конечные точки.

Общая конечная точка Azure AD:

https://login.microsoftonline.com/common

Конечная точка ресурсов для пакетной службы:

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

Дополнительные сведения о регистрации приложения пакетной службы в Microsoft Entra ID см. в статье Проверка подлинности служб пакетная служба Azure с помощью Microsoft Entra ID.