Авторизация с помощью общего ключа

Каждый запрос, сделанный в службе хранилища, должен быть авторизован, если запрос не предназначен для ресурса БОЛЬШОго двоичного объекта или контейнера, который был доступен для общедоступного или подписанного доступа. Одним из вариантов авторизации запроса является использование общего ключа, описанного в этой статье.

Службы BLOB-объектов, очередей, таблиц и файлов поддерживают следующие схемы авторизации общего ключа для версии 2009-09-19 и более поздних версий (для службы BLOB-объектов, очередей и таблиц) и версии 2014-02-14 и более поздних версий (для файловой службы):

• Общий ключ для BLOB-объектов, очередей и файловой службы. Используйте схему авторизации общего ключа для выполнения запросов к службам BLOB-объектов, очередей и файлов. Авторизация общего ключа в версии 2009-09-19 и более поздних версиях поддерживает строку дополненной подписи для повышения безопасности и требует обновления службы для авторизации с помощью этой дополненной подписи.

• Общий ключ для службы таблиц. Используйте схему авторизации общего ключа для выполнения запросов к службе таблиц с помощью REST API. Авторизация общего ключа для службы таблиц в версии 2009-09-19 и более поздних версий использует ту же строку сигнатуры, что и в предыдущих версиях службы таблиц.

• Общий ключ Lite. Используйте схему авторизации Lite общего ключа, чтобы выполнять запросы к службам BLOB-объектов, очередей, таблиц и файлов. Общий ключ Lite не поддерживается для больших двоичных объектов страниц класса Premium.

  Для версий 2009-09-19 и более поздних версий служб BLOB-объектов и очередей авторизация Lite общего ключа поддерживает использование строки подписи, идентичной поддерживаемым для общего ключа в предыдущих версиях служб BLOB-объектов и очередей. Поэтому вы можете использовать общий ключ Lite для выполнения запросов к службам BLOB-объектов и очередей, не обновляя строку подписи.

Для авторизованного запроса требуются два заголовка: заголовок Date или x-ms-date и заголовок Authorization. В следующих разделах описывается создание этих заголовков.

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

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

Службы хранилища гарантируют, что запрос не старше 15 минут до момента достижения службы. Это защищает от определенных атак безопасности, включая атаки воспроизведения. Если эта проверка завершается ошибкой, сервер возвращает код ответа 403 (запрещено).

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

Авторизованный запрос должен содержать заголовок Authorization. Если этот заголовок не включен, запрос является анонимным и успешно выполняется только для контейнера или большого двоичного объекта, помеченного для общедоступного доступа, или для контейнера, большого двоичного объекта, очереди или таблицы, для которой предоставлен подписанный URL-адрес для делегированного доступа.

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

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

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"  

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

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

Создание строки подписи

Как вы создаете строку подписи, зависит от того, какая служба и версия вы авторизируете и какую схему авторизации вы используете. При создании строки подписи помните следующее:

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

• Для авторизации общего ключа для служб BLOB-объектов, очередей и файлов каждый заголовок, включенный в строку подписи, может отображаться только один раз. Если любой заголовок дублируется, служба возвращает код состояния 400 (недопустимый запрос).

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

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

  Допустимо указать как x-ms-date, так и Date; В этом случае служба использует значение x-ms-date.

• Если заголовок x-ms-date не указан, укажите Date заголовок в строке подписи без включения имени заголовка.

• Все символы новой строки (\n) требуются в строке подписи.

• Строка подписи включает канонические заголовки и канонические строки ресурсов. Канонизация этих строк помещает их в стандартный формат, распознаваемый службой хранилища Azure. Подробные сведения о создании CanonicalizedHeaders и CanonicalizedResource строк, составляющих часть строки подписи, см. в следующих разделах.

BLOB-объекты, очереди и файловые службы (авторизация общего ключа)

Чтобы закодировать строку подписи общего ключа для запроса к версии 2009-09-19 и более поздних версий службы BLOB-объектов или очередей, а также версии 2014-02-14 и более поздних версий файловой службы используйте следующий формат:

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;  

В следующем примере показана строка подписи для операции Get Blob. Если нет значения заголовка, указан только символ новой строки.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20  

Разбиение этой строки вниз по строке показывает каждую часть одной строки:

GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length (empty string when zero)*/  
\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*/  
x-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/  

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

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Чтобы использовать авторизацию общего ключа с версией 2009-09-19 и более поздними службами BLOB-объектов и очередей, необходимо обновить код, чтобы использовать эту строку дополненной подписи.

Если вы предпочитаете перенести код на версию 2009-09-19 или более позднюю версию служб BLOB-объектов и очередей с наименьшими возможными изменениями, можно изменить существующие заголовки Authorization, чтобы использовать общий ключ Lite вместо общего ключа. Формат подписи, необходимый для Lite общего ключа, идентичен тому, что требуется для общего ключа версиями служб BLOB-объектов и очередей до 2009-09-19.

Заголовок Content-Length в версии 2014-02-14 и более ранних версиях

При использовании версии 2014-02-14 или более ранней, если Content-Length равно нулю, установите для Content-Length часть StringToSign значение 0. Обычно это пустая строка.

Например, для следующего запроса значение заголовка Content-Length включается в StringToSign даже если оно равно нулю.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1  
x-ms-version: 2014-02-14  
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT  
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  
Content-Length: 0

StringToSign создается следующим образом:

Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

В то время как в версиях после 2014-02-14 StringToSign должен содержать пустую строку для Content-Length:

Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Служба таблиц (авторизация общего ключа)

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

Строка подписи общего ключа для запроса к службе таблиц немного отличается от этой строки для запроса к службе BLOB-объектов или очередей, в которой она не включает CanonicalizedHeaders часть строки. Кроме того, заголовок Date в этом случае никогда не пуст, даже если запрос задает заголовок x-ms-date. Если запрос задает x-ms-date, это значение также используется для значения заголовка Date.

Чтобы закодировать строку подписи для запроса к службе таблиц, сделанной с помощью REST API, используйте следующий формат:

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedResource;  

BLOB-объекты, очереди и файловые службы (авторизация Lite с общим ключом)

Вы можете использовать авторизацию Lite общего ключа для авторизации запроса, сделанного в отношении версии 2009-09-19, а также более поздних версий служб BLOB-объектов и очередей, а также версии 2014-02-14 и более поздних версий файловых служб. Общий ключ Lite не поддерживается для больших двоичных объектов страниц класса Premium.

Строка подписи для Lite общего ключа идентична строке подписи, необходимой для авторизации общего ключа в версиях служб BLOB-объектов и очередей до 2009-09-19. Поэтому если вы хотите перенести код с наименьшим числом изменений в версии 2009-09-19 служб BLOB-объектов и очередей, вы можете изменить код, чтобы использовать общий ключ Lite, не изменяя сам строку подписи. Используя общий ключ Lite, вы не получите расширенные функции безопасности, предоставляемые с помощью общего ключа с версией 2009-09-19 и более поздними версиями.

Чтобы закодировать строку подписи для запроса к службе BLOB-объектов или очередей, используйте следующий формат:

StringToSign = VERB + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;  

В следующем примере показана строка подписи для операции Put BLOB-объектов. Обратите внимание, что строка заголовка Content-MD5 пуста. Заголовки, отображаемые в строке, — это пары "имя-значение", которые указывают пользовательские значения метаданных для нового большого двоичного объекта.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt  

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

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Служба таблиц (авторизация Lite с общим ключом)

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

Чтобы кодировать строку подписи для запроса к службе таблиц с помощью Lite общего ключа, используйте следующий формат:

StringToSign = Date + "\n"
               CanonicalizedResource  

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

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables  

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

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=  

Создание канонической строки заголовков

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

1. Извлеките все заголовки для ресурса, начинающегося с x-ms-, включая заголовок x-ms-date.

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

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

   Заметка

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

4. Замените любое линейное пробелы в значении заголовка одним пробелом.

Линейное пробелы включают канал возврата и линии каретки (CRLF), пробелы и вкладки. Дополнительные сведения см. RFC 2616, раздел 4.2. Не заменяйте пробелы внутри кавычки.

1. Обрезать любое пробелы вокруг двоеточия в заголовке.

2. Наконец, добавьте новый символ строки к каждому каноническому заголовку в результирующем списке. Создайте строку CanonicalizedHeaders путем объединения всех заголовков в этом списке в одну строку.

Ниже показан пример канонизированной строки заголовков:

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

Создание канонической строки ресурса

CanonicalizedResource часть строки подписи представляет ресурс служб хранилища, предназначенный для запроса. Любая часть строки CanonicalizedResource, производная от URI ресурса, должна быть закодирована точно так же, как в URI.

Для строки CanonicalizedResource поддерживается два поддерживаемых формата:

• Формат, поддерживающий авторизацию общего ключа для версии 2009-09-19 и более поздних версий служб BLOB-объектов и очередей, а также для версии 2014-02-14 и более поздних версий файловой службы.

• Формат, поддерживающий общий ключ и общий ключ Lite для всех версий службы таблиц, а также общий ключ Lite для версии 2009-09-19 и более поздних версий служб BLOB-объектов и очередей. Этот формат идентичен использованию предыдущих версий служб хранилища.

Сведения о создании URI для доступного ресурса см. в одном из следующих разделов:

• Служба BLOB-объектов: именование и ссылка на контейнеры, большие двоичные объекты и метаданные

• Служба очередей: адресация ресурсов службы очередей

• Служба таблиц: адресации ресурсов службы таблиц

• Файловая служба: именование и ссылка на общие папки, каталоги, файлы и метаданные

Формат общего ключа для 2009-09-19 и более поздних версий

Этот формат поддерживает авторизацию общего ключа для версии 2009-09-19 и более поздних версий служб BLOB-объектов и очередей, а также версии 2014-02-14 и более поздних версий файловых служб. Создайте строку CanonicalizedResource в этом формате следующим образом:

1. Начиная с пустой строки (""), добавьте косую черту (/), а затем имя учетной записи, которая владеет доступом к ресурсу.

2. Добавьте путь URI в кодировке ресурса без параметров запроса.

3. Извлеките все параметры запроса в URI ресурса, включая параметр comp, если он существует.

4. Преобразуйте все имена параметров в строчные регистры.

5. Сортировка параметров запроса лексографически по имени параметра в порядке возрастания.

6. Url-декодирование каждого параметра запроса и значения.

7. Добавьте новый символ строки (\n) перед каждой парой "имя-значение".

8. Добавьте имя и значение каждого параметра запроса в строку в следующем формате, убедитесь, что двоеточие (:) между именем и значением:

   parameter-name:parameter-value

9. Если параметр запроса имеет несколько значений, отсортируйте все значения лексографически, включите их в список с разделительной запятыми:

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

Имейте в виду следующие правила для создания канонизированной строки ресурса:

• Избегайте использования символа новой строки (\n) в значениях параметров запроса. Если его необходимо использовать, убедитесь, что он не влияет на формат канонической строки ресурса.

• Избегайте использования запятых в значениях параметров запроса.

Ниже приведены некоторые примеры, показывающие CanonicalizedResource часть строки подписи, так как ее можно создать из заданного URI запроса:

Get Container Metadata  
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:metadata\nrestype:container  
  
List Blobs operation:  
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs  
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container  
  
Get Blob operation against a resource in the secondary location:  
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob  
CanonicalizedResource:  
    /myaccount/mycontainer/myblob

Формат службы "Общий ключ" и "Таблица" для 2009-09-19 и более поздних версий

Этот формат поддерживает общий ключ и общий ключ Lite для всех версий службы таблиц и общего ключа для версии 2009-09-19 и более поздних версий служб BLOB-объектов и очередей и версии 2014-02-14 и более поздних версий файловой службы. Этот формат идентичен использованию предыдущих версий служб хранилища. Создайте строку CanonicalizedResource в этом формате следующим образом:

1. Начиная с пустой строки (""), добавьте косую черту (/), а затем имя учетной записи, которая владеет доступом к ресурсу.

2. Добавьте путь URI в кодировке ресурса. Если URI запроса обращается к компоненту ресурса, добавьте соответствующую строку запроса. Строка запроса должна содержать вопросительный знак и параметр comp (например, ?comp=metadata). Другие параметры не должны быть включены в строку запроса.

Кодировка подписи

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

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))  

См. также

• REST API службы BLOB-объектов
• REST API службы очередей
• REST API службы таблиц
• REST служб хранилища