VENDAS: 1-800-867-1389

Autenticação federada para os Serviços de Armazenamento do Azure

Atualizado: maio de 2014

Cada solicitação feita em um serviço de armazenamento deve ser autenticada, a menos que a solicitação seja para um recurso de blob ou contêiner que tenha sido disponibilizado para o acesso público ou assinado.

ImportantImportante
Os serviços de armazenamento do Microsoft Azure oferecem suporte ao HTTP e HTTPS. No entanto, usar HTTPS é altamente recomendável.

Os serviços Blob, Fila, Tabela e Arquivos oferecem suporte aos seguintes esquemas de autenticação de chave compartilhada, começando com a versão 2009-09-19 (para Serviço Blob, Fila e Tabela) e versão 2014-02-14 (para o serviço de Arquivo):

  • Chave Compartilhada para serviços Blob, Fila e Arquivo. Use o esquema de autenticação de Chave Compartilhada para fazer solicitações nos serviços Blob, Fila e Arquivo. A autenticação de Chave Compartilhada na versão 2009-09-19 oferece suporte a uma cadeia de caracteres de assinatura aumentada para segurança aprimorada e requer que você atualize seu serviço para se autenticar usando essa assinatura aumentada.

  • Chave Compartilhada para o serviço Tabela. Use o esquema de autenticação de Chave Compartilhada para fazer solicitações no serviço Tabela usando a API REST. A autenticação de Chave Compartilhada para o serviço Tabela na versão 2009-09-19 usa a mesma cadeia de caracteres de assinatura de versões anteriores do serviço Tabela.

  • Shared Key Lite. Use o esquema de autenticação Shared Key Lite para fazer solicitações nos serviços Blob, Fila, Tabela e Arquivo.

    Para a versão 2009-09-19 dos serviços Blob e Fila, a autenticação Shared Key Lite oferece suporte ao uso de uma cadeia de caracteres de assinatura idêntica à que tinha suporte na Chave Compartilhada nas versões anteriores dos serviços Blob e Fila. Assim, você pode usar a Shared Key Lite para fazer solicitações nos serviços Blob e Fila, sem atualizar a cadeia de caracteres da assinatura.

Uma solicitação autenticada requer dois cabeçalhos: o cabeçalho Date ou x-ms-date e o cabeçalho Authorization. As seções a seguir descrevem como construir esses cabeçalhos.

noteObservação
Um contêiner ou blob pode ser disponibilizado para acesso público definindo-se as permissões do contêiner. Para obter mais informações, consulte Gerenciar acesso aos recursos de armazenamento do Azure. Um contêiner, blob, fila ou tabela podem ser disponibilizados para acesso assinado via uma assinatura de acesso compartilhado. A assinatura de acesso compartilhado é autenticada por meio de um mecanismo diferente. Consulte Delegando acesso com uma assinatura de acesso compartilhado para obter mais detalhes.

Todas as solicitações autenticadas devem incluir o carimbo de data/hora de UTC (Tempo Universal Coordenado) para a solicitação. Você pode especificar o carimbo de data/hora no cabeçalho x-ms-date ou no cabeçalho Date HTTP/HTTPS padrão. Se ambos os cabeçalhos forem especificados na solicitação, o valor x-ms-date será usado como a hora de criação da solicitação.

Os serviços de armazenamento garantem que uma solicitação não tenha mais de 15 minutos antes de atingir o serviço. Isso protege contra certos ataques de segurança, incluindo ataques de reprodução. Quando essa verificação falha, o servidor retorna o código de resposta 403 (Proibido).

noteObservação
O cabeçalho x-ms-date é fornecido porque algumas bibliotecas de clientes HTTP e proxies definem automaticamente o cabeçalho Date e não oferecem ao desenvolvedor uma oportunidade de ler seu valor para incluí-lo na solicitação autenticada. Se você definir x-ms-date, criará a assinatura com um valor vazio para o cabeçalho Date.

Uma solicitação autenticada deve incluir o cabeçalho Authorization. Se esse cabeçalho não for incluído, a solicitação será anônima e só ocorrerá em um contêiner ou blob que esteja marcado para acesso público, ou em um contêiner, blob, fila ou tabela para os quais uma assinatura de acesso compartilhado tenha sido fornecida para acesso delegado.

Para autenticar uma solicitação, você deve assiná-la com a chave da conta que está fazendo a solicitação e passar essa assinatura como parte da solicitação.

O formato do cabeçalho Authorization é o seguinte:

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

onde SharedKey ou SharedKeyLite é o nome do esquema de autorização, AccountName é o nome da conta que solicita o recurso e Signature é um código HMAC (Hash-based Message Authentication Code) construído com base na solicitação e computado com o uso do algoritmo SHA256 e codificado na Base64.

noteObservação
É possível solicitar um recurso que resida sob uma conta diferente, se esse recurso estiver publicamente acessível.

As seções a seguir descrevem como construir o cabeçalho Authorization.

O modo como você constrói a cadeia de caracteres de assinatura depende do serviço, da versão e do esquema de autenticação usados. Ao construir a cadeia de caracteres de assinatura, tenha em mente o seguinte:

  • A parte VERB de cadeia de caracteres é o verbo HTTP, como GET ou PUT, e deve ser maiúscula.

  • Para a autenticação de Chave Compartilhada dos serviços Blob, Fila e Arquivo, cada cabeçalho incluído na cadeia de caracteres da assinatura pode aparecer apenas uma vez. Se um cabeçalho estiver duplicado, o serviço retornará o código de status 400 (Solicitação Incorreta).

  • Os valores de todos os cabeçalhos HTTP padrão devem ser incluídos na cadeia de caracteres na ordem mostrada no formato de assinatura, sem os nomes de cabeçalho. Esses cabeçalhos poderão ficar vazios se não estiverem sendo especificados como parte da solicitação; nesse caso, somente o caractere de nova linha será necessário.

  • Se o cabeçalho x-ms-date for especificado, você poderá ignorar o cabeçalho Date, quer seja especificado na solicitação ou não, e simplesmente especificar uma linha vazia para a parte Date da cadeia de caracteres da assinatura. Nesse caso, siga as instruções na seção Construindo o elemento CanonicalizedHeaders para adicionar o cabeçalho x-ms-date.

    Observe que é aceitável especificar tanto x-ms-date quanto Date; nesse caso, o serviço usará o valor x-ms-date.

  • Se o cabeçalho x-ms-date não for especificado, especifique o cabeçalho Date na cadeia de caracteres de assinatura, sem incluir o nome do cabeçalho.

  • Todos os caracteres de nova linha (\n) mostrados devem estar dentro da cadeia de caracteres da assinatura.

  • Para obter informações detalhadas sobre como construir as cadeias de caracteres CanonicalizedHeaders e CanonicalizedResource que fazem parte da cadeia de caracteres de assinatura, consulte as seções apropriadas posteriormente neste tópico.

Para codificar a cadeia de caracteres da assinatura de Chave Compartilhada para uma solicitação na versão 2009-09-19 ou acima do serviço Blob ou Fila, e versão 2014-02-14 use o seguinte formato:

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;

O exemplo a seguir mostra uma cadeia de caracteres de assinatura para uma operação Obter Blob. Observe que onde não há nenhum valor de cabeçalho, somente o caractere de nova linha é especificado.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

A análise disso linha por linha mostra cada parte da mesma cadeia de caracteres:


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*/
x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/
/myaccount/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

Em seguida, codifique essa cadeia de caracteres usando o algoritmo HMAC-SHA256 sobre a cadeia de caracteres de assinatura com codificação UTF-8, construa o cabeçalho Authorization e adicione o cabeçalho à solicitação. O exemplo a seguir mostra o cabeçalho Authorization para a mesma operação:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Observe que, para usar a autenticação de Chave Compartilhada com as versões 2009-09-19 dos serviços Blob e Fila, você deve atualizar seu código para usar essa cadeia de caracteres de assinatura aumentada.

Se preferir migrar seu código para as versões 2009-09-19 dos serviços Blob e Fila com o menor número possível de alterações, você poderá alterar os cabeçalhos Authorization existentes para usar uma Shared Key Lite, em vez da Chave Compartilhada. O formato de assinatura necessário para a Shared Key Lite é idêntico ao necessário para a Chave Compartilhada por versões dos serviços Blob e Fila anteriores à versão 2009-09-19.

Você deve usar a autenticação de Chave Compartilhada para autenticar uma solicitação feita no serviço Tabela, se o serviço estiver usando a API REST para fazer a solicitação. O formato da cadeia de caracteres de assinatura para a Chave Compartilhada no serviço Tabela é igual para todas as versões.

Observe que a cadeia de caracteres de assinatura da Chave Compartilhada para uma solicitação no serviço Tabela difere ligeiramente daquela para uma solicitação nos serviços Blob ou Fila, pois não inclui a parte CanonicalizedHeaders da cadeia de caracteres. Além disso, o cabeçalho Date nesse caso nunca fica vazio, mesmo que a solicitação defina o cabeçalho x-ms-date. Se a solicitação definir x-ms-date, esse valor será usado também para o valor do cabeçalho Date.

Para codificar a cadeia de caracteres de assinatura para uma solicitação no serviço Tabela feita com a API REST, use o seguinte formato:

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

noteObservação
A partir da versão 2009-09-19, o serviço Tabela exige que todas as chamadas REST incluam os cabeçalhos DataServiceVersion e MaxDataServiceVersion. Consulte Definindo os cabeçalhos da versão do serviço de dados OData para obter mais informações.

Você pode usar a autenticação Shared Key Lite para autenticar uma solicitação feita na versão 2009-09-19 dos serviços Blob e Fila e a versão 2014-02-14 dos serviços Arquivo.

A cadeia de caracteres de assinatura para Shared Key Lite é idêntica à cadeia de caracteres de assinatura necessária para a autenticação de Chave Compartilhada nas versões dos serviços Blob e Fila anteriores à versão 2009-09-19. Portanto, se você quiser migrar seu código com o menor número de alterações para as versões 2009-09-19 dos serviços Blob e Fila, poderá modificar seu código para usar a Shared Key Lite, sem alterar a cadeia de caracteres de assinatura em si. Observe que ao usar a Shared Key Lite, você não obterá a funcionalidade de segurança aprimorada proporcionada com o uso da Chave Compartilhada com a versão 2009-09-19 da API.

Para codificar a cadeia de caracteres de assinatura para uma solicitação no serviço Blob ou Fila, use o seguinte formato:

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

O exemplo a seguir mostra uma cadeia de caracteres de assinatura para uma operação Colocar Blob. Observe que a linha de cabeçalho Content-MD5 está vazia. Os cabeçalhos mostrados na cadeia de caracteres são os pares de nome-valor que especificam valores personalizados de metadados para o novo blob.

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

Em seguida, codifique essa cadeia de caracteres usando o algoritmo HMAC-SHA256 sobre a cadeia de caracteres de assinatura com codificação UTF-8, construa o cabeçalho Authorization e adicione o cabeçalho à solicitação. O exemplo a seguir mostra o cabeçalho Authorization para a mesma operação:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Você pode usar a autenticação Shared Key Lite para autenticar uma solicitação feita em qualquer versão do serviço Tabela.

Para codificar a cadeia de caracteres de assinatura para uma solicitação no serviço Tabela usando Shared Key Lite, use o seguinte formato:

StringToSign = Date + "\n" 
               CanonicalizedResource

O exemplo a seguir mostra uma cadeia de caracteres de assinatura para uma operação Criar tabela.

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

Em seguida, codifique essa cadeia de caracteres usando o algoritmo HMAC-SHA256, construa o cabeçalho Authorization e adicione o cabeçalho à solicitação. O exemplo a seguir mostra o cabeçalho Authorization para a mesma operação:

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

Para construir a parte CanonicalizedHeaders de cadeia de caracteres de assinatura, siga estas etapas:

  1. Recupere todos os cabeçalhos para o recurso que começam com x-ms-, incluindo o cabeçalho x-ms-date.

  2. Converta cada nome de cabeçalho HTTP em minúsculas.

  3. Classifique os cabeçalhos de modo lexicográfico pelo nome do cabeçalho, em ordem crescente. Observe que cada cabeçalho pode aparecer apenas uma vez na cadeia de caracteres.

  4. Desdobre a cadeia de caracteres substituindo qualquer espaço em branco de quebra com um único espaço.

  5. Exclui todo o espaço em branco em torno de dois-pontos no cabeçalho.

  6. Finalmente, acrescente um caractere de nova linha para cada cabeçalho canonizado na lista resultante. Construa a cadeia de caracteres CanonicalizedHeaders concatenando todos os cabeçalhos nessa lista em uma única cadeia de caracteres.

A parte CanonicalizedResource da cadeia de caracteres de assinatura representa o recurso de serviços de armazenamento de destino da solicitação. Qualquer parte da cadeia de caracteres de CanonicalizedResource que seja derivada do URI do recurso deverá ser codificada exatamente como em seu URI.

Há dois formatos com suporte para a cadeia de caracteres de CanonicalizedResource:

  • Um formato que oferece suporte à autenticação de Chave Compartilhada para a versão 2009-09-19 dos serviços Blob e Fila e para a 2014-02-14 do serviço Arquivo.

  • Um formato que oferece suporte à Chave Compartilhada e à Shared Key Lite para todas as versões do serviço Tabela, e Shared Key Lite para a versão 2009-09-19 dos serviços Blob e Fila. Esse formato é idêntico àquele usado com as versões anteriores dos serviços de armazenamento.

Para obter ajuda ao construir o URI do recurso que você está acessando, consulte um dos seguintes tópicos:

noteObservação
Se você estiver autenticando no emulador de armazenamento, o nome da conta aparecerá duas vezes na cadeia de caracteres de CanonicalizedResource. Isso é esperado. Se você estiver autenticando nos serviços de armazenamento do Windows Azure, o nome da conta aparecerá apenas uma vez na cadeia de caracteres de CanonicalizedResource.

Formato de Chave Compartilhada 2009-09-19

Este formato suporta a autenticação de Chave Compartilhada para a versão 2009-09-19 dos serviços Blob e Fila e para a 2014-02-14 dos serviços de Arquivo. Construa a cadeia de caracteres de CanonicalizedResource nesse formato, da seguinte maneira:

  1. Comece com uma cadeia de caracteres vazia (""), acrescente uma barra (/), seguida pelo nome da conta que tem o recurso sendo acessado.

  2. Acrescente o caminho do URI codificado do recurso, sem nenhum parâmetro de consulta.

  3. Recupere todos os parâmetros de consulta no URI de recurso, incluindo o parâmetro comp, se existir.

  4. Converta todos os nomes de parâmetro em minúsculas.

  5. Classifique os parâmetros de consulta de modo lexicográfico pelo nome do parâmetro, em ordem crescente.

  6. Decodifique com URL todos os nomes e valores de parâmetro de consulta.

  7. Acrescente cada nome e valor de parâmetro de consulta à cadeia de caracteres no seguinte formato, certificando-se incluir os dois-pontos (:) entre o nome e o valor:

    parameter-name:parameter-value

  8. Se um parâmetro de consulta tiver mais de um valor, classifique todos os valores de modo lexicográfico e inclua-os em uma lista separada por vírgulas:

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

  9. Acrescente um caractere de nova linha (\n) após cada par de nome-valor.

Lembre-se das seguintes regras para construir a cadeia de caracteres de recurso canonizado:

  • Evite usar o caractere de nova linha (\n) nos valores para parâmetros de consulta. Se for necessário usá-lo, verifique se não afeta o formato da cadeia de caracteres de recurso canonizado.

  • Evite usar vírgulas em valores de parâmetro de consulta.

Veja alguns exemplos que mostram a parte CanonicalizedResource da cadeia de caracteres de assinatura, pois ela pode ser construída com base em um determinado URI de solicitação:


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

Shared Key Lite e formato de serviço Tabela 2009-09-19

Este formato que oferece suporte à Chave Compartilhada e à Shared Key Lite para todas as versões do serviço Tabela, e Shared Key Lite para a versão 2009-09-19 dos serviços Blob e Fila e 2014-02-14 de serviço de Arquivo. Esse formato é idêntico àquele usado com as versões anteriores dos serviços de armazenamento. Construa a cadeia de caracteres de CanonicalizedResource nesse formato, da seguinte maneira:

  1. Comece com uma cadeia de caracteres vazia (""), acrescente uma barra (/), seguida pelo nome da conta que tem o recurso sendo acessado.

  2. Acrescente o caminho de URI codificado do recurso. Se o URI da solicitação abordar um componente de recurso, acrescente a cadeia de caracteres de consulta apropriada. A cadeia de caracteres de consulta deve incluir o ponto de interrogação e o parâmetro comp (por exemplo, ?comp=metadata). Nenhum outro parâmetro deve ser incluído na cadeia de caracteres da consulta.

Para codificar a assinatura, chame o algoritmo HMAC-SHA256 na cadeia de caracteres de assinatura de com codificação UTF-8 codificar o resultado na Base64. Use o seguinte formato (mostrado como pseudocódigo):

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

Consulte também

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft