Autenticação federada para os Serviços de Armazenamento do Azure
Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

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

 

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.

System_CAPS_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 Arquivo suportam os seguintes esquemas de autenticação de chave compartilhada da versão 2009-09-19 e posterior (para o serviço Blob, Fila e Tabela) e versão de 2014-02-14 e posterior (para serviços 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 e posterior 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 e posterior 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 e posterior 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 Date ou x-ms-date cabeçalho e o Authorization cabeçalho. As seções a seguir descrevem como construir esses cabeçalhos.

System_CAPS_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 Delegar 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 hora ou no x-ms-date cabeçalho, ou em HTTP/HTTPS padrão Date cabeçalho. Se ambos os cabeçalhos forem especificados na solicitação, o valor de x-ms-date é usado como a hora da solicitação de criaçã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).

System_CAPS_noteObservação

A palavras-chave Async e Await no Visual Basic e a palavras-chave async e await em c# são o coração da programação assíncrona. Se você definir x-ms-date, construir a assinatura com um valor vazio para o Date cabeçalho.

Uma solicitação autenticada deve incluir o Authorization cabeçalho. 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 para o Authorization cabeçalho é 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 de autenticação de mensagem baseada em Hash (HMAC) construída a partir da solicitação e computado usando o algoritmo SHA256 e codificado usando a codificação Base64.

System_CAPS_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 Authorization cabeçalho.

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 podem ficar vazios se não estiverem sendo especificados como parte da solicitação; nesse caso, somente o caractere de nova linha é necessário.

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

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

  • Se o x-ms-date cabeçalho não for especificado, especifique o Date cabeçalho na cadeia 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.

  • A cadeia de caracteres da assinatura inclui cabeçalhos canonizado e cadeias de caracteres de recurso canonizadas. Canonizar estas cadeias de caracteres as coloca em um formato padrão que é reconhecido pelo Armazenamento do Azure. Para obter informações detalhadas sobre como construir o CanonicalizedHeaders e CanonicalizedResource cadeias de caracteres 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 e posterior ou superior do serviço Blob ou Fila e versão 2014-02-14 e posterior do serviço Arquivo, 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 um Obter Blob operação. 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/ 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 (include value 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:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/ /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 codificado em UTF-8, construa o Authorization cabeçalho, e adicione o cabeçalho à solicitação. A exemplo a seguir mostra o Authorization cabeçalho para a mesma operação:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

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

Se você preferir migrar seu código para a versão 2009-09-19 ou posterior dos serviços Blob e fila com os menor número de possíveis alterações, você pode modificar as existentes Authorization cabeçalhos usar Shared Key Lite, em vez de 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.

System_CAPS_importantImportante

Se você estiver acessando o local secundário em uma conta de armazenamento para os quais o acesso de leitura a replicação geográfica (RA-GRS) é habilitada, não inclua o -secondary designação no cabeçalho de autorização. Para fins de autorização, o nome da conta é sempre o nome do local principal, mesmo para acesso secundário.

Ao usar a versão 2015-02-21 ou mais tarde, se Content-Length for zero, em seguida, defina o Content-Length faz parte do StringToSign para uma cadeia de caracteres vazia.

Por exemplo, para a solicitação a seguir, o valor da Content-Length cabeçalho é omitido do StringToSign quando for zero.

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

A palavras-chave Async e Await no Visual Basic e a palavras-chave async e await em c# são o coração da programação assíncrona.

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

Enquanto em versões anteriores de 2015-02-21, o StringToSign deve incluir o valor zero para Content-Length:

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:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

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 de chave compartilhada para uma solicitação no serviço tabela difere ligeiramente para uma solicitação no serviço Blob ou fila, pois ele não inclui o CanonicalizedHeaders parte da cadeia de caracteres. Além disso, o Date cabeçalho nesse caso nunca está vazio mesmo se a solicitação define o x-ms-date cabeçalho. Se a solicitação define x-ms-date, que o valor também é usado para o valor da Date cabeçalho.

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;

System_CAPS_noteObservação

A partir da versão 2009-09-19, o serviço tabela exige que todas as chamadas REST incluam o DataServiceVersion e MaxDataServiceVersion cabeçalhos. 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 e posterior dos serviços Blob e Fila e na versão 2014-02-14 e posterior 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 a versão 2009-09-19 dos serviços Blob e fila, você pode modificar o código para usar o 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 e posterior.

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 um Colocar Blob operação. 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 codificado em UTF-8, construa o Authorization cabeçalho, e adicione o cabeçalho à solicitação. A exemplo a seguir mostra o Authorization cabeçalho 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 um Criar tabela operação.

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 Authorization cabeçalho, e, em seguida, adicione o cabeçalho à solicitação. A exemplo a seguir mostra o Authorization cabeçalho para a mesma operação:

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

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

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

  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.

    System_CAPS_noteObservação

    Ordenação lexicográficas talvez nem sempre coincide com ordem alfabética convencional.

  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. Construir o CanonicalizedHeaders cadeia de caracteres concatenando todos os cabeçalhos nessa lista em uma única cadeia de caracteres.

A seguir é exibido um exemplo de cadeia de caracteres dos cabeçalhos canonizados:

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

A palavras-chave Async e Await no Visual Basic e a palavras-chave async e await em c# são o coração da programação assíncrona. Qualquer parte do CanonicalizedResource cadeia de caracteres que é derivada do URI do recurso deve ser codificada exatamente como é no URI.

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

  • Um formato que oferece suporte à autenticação de Chave Compartilhada para a versão 2009-09-19 e posterior dos serviços Blob e Fila e para a versão 2014-02-14 e posterior 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 e posterior 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:

System_CAPS_importantImportante

Se sua conta de armazenamento é replicada com acesso de leitura a replicação geográfica (RA-GRS), e você estiver acessando um recurso no local secundário, não inclua o –secondary designação de CanonicalizedResource cadeia de caracteres. O recurso de URI usado no CanonicalizedResource URI de cadeia de caracteres deve ser o URI do recurso no local principal.

System_CAPS_noteObservação

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

Formato da chave compartilhada da versão 2009-09-19 e posterior

Um formato que oferece suporte à autenticação de Chave Compartilhada para a versão 2009-09-19 e posterior e posterior dos serviços Blob e Fila e para a versão 2014-02-14 e posterior dos serviços de Arquivo. Construir o CanonicalizedResource de cadeia de caracteres neste 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. Acrescente um caractere de nova linha (\n) após o nome do recurso.

  4. Recuperar todos os parâmetros de consulta no URI de recurso, incluindo o comp parâmetro se ele existir.

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

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

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

  8. 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

  9. 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

  10. Acrescente um caractere de nova linha (\n) após cada par 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 de 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.

Aqui estão alguns exemplos que mostram o CanonicalizedResource parte da assinatura de cadeia de caracteres, como pode ser construída a partir de 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 Get Blob operation against a resource in the secondary location: GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob CanonicalizedResource: /myaccount/mycontainer/myblob


Formato de serviço Tabela e Shared Key Lite da versão 2009-09-19 e posterior

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 e posterior dos serviços Blob e Fila e para a versão 2014-02-14 e posterior do serviço Arquivo. Esse formato é idêntico àquele usado com as versões anteriores dos serviços de armazenamento. Construir o CanonicalizedResource de cadeia de caracteres neste 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 comp parâmetro (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)))
Mostrar:
© 2016 Microsoft