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

Каждый запрос к службе Batch должен пройти проверку подлинности. Пакетная служба поддерживает проверку подлинности с помощью общего ключа или Azure Active Directory (Azure AD).

Проверка подлинности через общий ключ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Если указан заголовок " OCP-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: 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)))  

Проверка подлинности с помощью Azure AD

Azure AD — многопользовательский облачный каталог и служба управления удостоверениями корпорации Майкрософт. Пакетная служба поддерживает проверку подлинности в Azure AD.

Примечание

Аутентификация с помощью Azure AD необходима только в том случае, если учетная запись пакетной службы настроена на выделение пулов в подписке пользователя. Параметр распределения пула доступен при создании новой учетной записи пакетной службы. Если ваша учетная запись настроена на выделение пулов в подписке, управляемой пакетной службой, то использовать Azure AD для проверки подлинности необязательно. Дополнительные сведения см. в разделе Пакетная поддержка виртуальной сети и пользовательских образов для пулов виртуальных машин.

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

Конечная точка конечной точки Azure AD "Common":

https://login.microsoftonline.com/common

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

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

Дополнительные сведения о регистрации приложения пакетной службы в Azure AD см. в статье Проверка подлинности в пакетных решениях с помощью Active Directory.