VENTAS: 1-800-867-1389

Autenticación para los servicios de almacenamiento de Azure

Actualizado: mayo de 2014

Las solicitudes realizadas en un servicio de almacenamiento deben autenticarse, a menos que la solicitud sea para un recurso de blob o de contenedor que esté disponible para el acceso público o el acceso firmado.

ImportantImportante
Los servicios de almacenamiento de Microsoft Azure admiten HTTP y HTTPS; sin embargo, es muy recomendable utilizar HTTPS.

Los servicios Blob, Cola, Tabla y Archivo admiten los esquemas de autenticación Clave compartida siguientes a partir de la versión 2009-09-19 (para el servicio Blob, Cola y Tabla) y la versión 14-02-2014 (para el servicio Archivo):

  • Clave compartida para los servicios Blob, Cola y Archivo. Usa el esquema de autenticación Clave compartida para realizar solicitudes respecto a los servicios Blob, Cola y Archivo. La autenticación Shared Key en la versión 2009-09-19 admite una cadena de firma aumentada para mejorar la seguridad y requiere la actualización del servicio para la autenticación mediante esta firma aumentada.

  • Shared Key para el servicio Tabla. Utilice el esquema de autenticación Shared Key para realizar solicitudes en el servicio Tabla utilizando la API de REST. La autenticación Shared Key para el servicio Tabla en la versión 2009-09-19 utiliza la misma cadena de firma que en versiones anteriores de dicho servicio.

  • Shared Key Lite. Usa el esquema de autenticación de Clave compartida ligera para realizar solicitudes respecto a los servicios Blob, Cola, Tabla y Archivo.

    En la versión 2009-09-19 de los servicios Blob y Cola, la autenticación Shared Key Lite admite el uso de una cadena de firma idéntica a la admitida en Shared Key en versiones anteriores de dichos servicios. Por tanto, puede utilizar Shared Key Lite para realizar solicitudes en los servicios Blob y Cola sin actualizar la cadena de firma.

Una solicitud autenticada requiere dos encabezados: el encabezado Date o x-ms-date y el encabezado Authorization. En las secciones siguientes se describe cómo construir estos encabezados.

noteNota
Es posible hacer que un contenedor o un blob estén disponibles para el acceso público estableciendo los permisos de su contenedor. Para obtener más información, vea Administrar el acceso a los recursos de almacenamiento de Azure. Un contenedor, un blob, una cola o una tabla pueden estar disponibles para el acceso firmado a través de una firma de acceso compartido; una firma de acceso compartido se autentica mediante un mecanismo diferente. Vea Delegar el acceso con una firma de acceso compartido para obtener más detalles.

Todas las solicitudes autenticadas deben incluir la marca de tiempo de hora universal coordinada (UTC) para la solicitud. Puede especificar la marca de tiempo en el encabezado x-ms-date o en el encabezado HTTP/HTTPS Date estándar. Si se especifican ambos encabezados en la solicitud, el valor de x-ms-date se utiliza como el momento de creación de la solicitud.

Los servicios de almacenamiento comprueban que una solicitud tenga una antigüedad no superior a 15 minutos en el momento en que alcanza el servicio. Esto evita determinados ataques de seguridad, incluidos los ataques de reproducción. Si se produce un error en esta comprobación, el servidor devuelve el código de respuesta 403 (Prohibido).

noteNota
Se proporciona el encabezado x-ms-date debido a que algunas bibliotecas de cliente y servidores proxy HTTP establecen automáticamente el encabezado Date, y no dan al desarrollador la oportunidad de leer su valor para incluirlo en la solicitud autenticada. Si establece x-ms-date, cree la firma con un valor vacío para el encabezado Date.

Una solicitud autenticada debe incluir el encabezado Authorization. Si no lo incluye, la solicitud será anónima y solo se realizará correctamente en un contenedor o blob que esté marcado para acceso público, o bien en un contenedor, un blob, una cola o una tabla para los que se haya proporcionado una firma de acceso compartido para acceso delegado.

Para autenticar una solicitud, debe firmarla con la clave de la cuenta que la realiza y pasar esa firma como parte de la solicitud.

El formato del encabezado Authorization es el siguiente:

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

donde SharedKey o SharedKeyLite es el nombre del esquema de autorización, AccountName es el nombre de la cuenta que solicita el recurso, y Signature es un código de autentificación de mensajes basado en hash (HMAC) construido a partir de la solicitud, calculado mediante el algoritmo SHA256 y, por último, codificado utilizando la codificación Base64.

noteNota
Es posible solicitar un recurso que resida en una cuenta diferente, siempre que ese recurso sea accesible públicamente.

En las secciones siguientes se describe cómo construir el encabezado Authorization.

El modo de construir la cadena de firma depende del servicio y la versión en los que esté realizando la autenticación y del esquema de autenticación que utilice. Al construir la cadena de firma, tenga en cuenta lo siguiente:

  • La parte VERB de la cadena es el verbo HTTP, como GET o PUT, y debe estar en mayúsculas.

  • En la autenticación Clave compartida para los servicios Blob, Cola y Archivo, cada encabezado incluido en la cadena de firma solo puede aparecer una vez. Si hay algún encabezado duplicado, el servicio devuelve el código de estado 400 (Solicitud incorrecta).

  • Los valores de todos los encabezados HTTP estándar deben incluirse en la cadena en el orden mostrado en el formato de la firma, sin los nombres de encabezado. Estos encabezados pueden estar vacíos si no se especifican como parte de la solicitud; en ese caso, solo se requiere el carácter de nueva línea.

  • Si se especifica el encabezado x-ms-date, puede omitir el encabezado Date, independientemente de si se especifica este en la solicitud, y especificar simplemente una línea vacía para la parte Date de la cadena de firma. En este caso, siga las instrucciones descritas en la sección Construir la cadena CanonicalizedHeaders para agregar el encabezado x-ms-date.

    Tenga en cuenta que es aceptable especificar los dos encabezados x-ms-date y Date; en este caso, el servicio utiliza el valor de x-ms-date.

  • Si el encabezado x-ms-date no se especifica, especifique el encabezado Date en la cadena de firma, sin incluir el nombre de encabezado.

  • Todos los caracteres de nueva línea (\n) mostrados se deben incluir en la cadena de firma.

  • Para obtener información detallada sobre la construcción de las cadenas CanonicalizedHeaders y CanonicalizedResource que forman parte de la cadena de firma, vea las secciones adecuadas más adelante en este tema.

Para codificar la cadena de firma Clave compartida de una solicitud en la versión 19-09-2009 o superior del servicio Blob o Cola, y la versión 14-02-2014 o superior del servicio Archivo, usa el formato siguiente:

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;

En el ejemplo siguiente se muestra una cadena de firma para una operación Get Blob. Tenga en cuenta que, cuando no hay ningún valor de encabezado, solo se especifica el carácter de nueva línea.

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

Si se analiza esta cadena línea a línea, se puede ver cada parte de la misma:


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

A continuación, codifique esta cadena utilizando el algoritmo HMAC-SHA256 en la cadena de firma codificada mediante UTF-8, construya el encabezado Authorization y, por último, agréguelo a la solicitud. En el ejemplo siguiente se muestra el encabezado Authorization para la misma operación:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Tenga en cuenta que para utilizar la autenticación Shared Key con las versiones 2009-09-19 de los servicios Blob y Cola, debe actualizar el código para utilizar esta cadena de firma aumentada.

Si prefiere migrar el código a las versiones 2009-09-19 de los servicios Blob y Cola con el menor número de cambios posible, puede modificar los encabezados Authorization existentes para utilizar Shared Key Lite en lugar de Shared Key. El formato de firma que requiere Shared Key Lite es idéntico al requerido por Shared Key en las versiones de los servicios Blob y Cola anteriores a la versión 2009-09-19.

Debe utilizar la autenticación Shared Key para autenticar una solicitud realizada en el servicio Tabla si el servicio utiliza la API de REST para realizar la solicitud. El formato de la cadena de firma para Shared Key en el servicio Tabla es el mismo para todas las versiones.

Tenga en cuenta que la cadena de firma Shared Key de una solicitud en el servicio Tabla difiere ligeramente de la de una solicitud en el servicio Blob o Cola, ya que no incluye la parte CanonicalizedHeaders de la cadena. Además, en este caso el encabezado Date nunca está vacío, aunque la solicitud establezca el encabezado x-ms-date. Si la solicitud establece x-ms-date, este valor también se utiliza para el valor del encabezado Date.

Para codificar la cadena de firma de una solicitud en el servicio Tabla mediante la API de REST, utilice el formato siguiente:

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

noteNota
A partir de la versión 2009-09-19, el servicio Tabla requiere que todas las llamadas a REST incluyan los encabezados DataServiceVersion y MaxDataServiceVersion. Vea Establecer los encabezados de versión del servicio de datos OData para obtener más información.

Puede usar la autenticación Clave compartida ligera para autenticar una solicitud realizada en la versión 19-09-2009 de los servicios Blob y Cola, y la versión 14-02-2014 del servicio Archivo.

La cadena de firma para Shared Key Lite es idéntica a la cadena de firma que requiere la autenticación Shared Key en las versiones de los servicios Blob y Cola anteriores a la versión 2009-09-19. Por lo tanto, si desea migrar su código con el menor número de cambios a las versiones 2009-09-19 de los servicios Blob y Cola, puede modificar su código para usar Shared Key Lite sin cambiar la propia cadena de firma. Tenga en cuenta que con Shared Key Lite no dispondrá de la funcionalidad de seguridad mejorada que ofrece Shared Key con la versión 2009-09-19 de la API.

Para codificar la cadena de firma de una solicitud en el servicio Blob o Cola, utilice el formato siguiente:

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

En el ejemplo siguiente se muestra una cadena de firma para una operación Put Blob. Observe que la línea de encabezado Content-MD5 está vacía. Los encabezados mostrados en la cadena son pares nombre-valor que especifican valores de metadatos personalizados para el nuevo 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

A continuación, codifique esta cadena utilizando el algoritmo HMAC-SHA256 en la cadena de firma codificada mediante UTF-8, construya el encabezado Authorization y, por último, agréguelo a la solicitud. En el ejemplo siguiente se muestra el encabezado Authorization para la misma operación:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Se puede usar la autenticación Shared Key Lite para autenticar una solicitud realizada contra cualquier versión del servicio Tabla.

Para codificar la cadena de firma para una solicitud contra el servicio Tabla usando Shared Key Lite, use el formato siguiente:

StringToSign = Date + "\n" 
               CanonicalizedResource

En el ejemplo siguiente se muestra una cadena de firma para una operación Create Table.

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

A continuación, codifique esta cadena utilizando el algoritmo HMAC-SHA256, construya el encabezado Authorization y, por último, agréguelo a la solicitud. En el ejemplo siguiente se muestra el encabezado Authorization para la misma operación:

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

Para construir a la parte CanonicalizedHeaders de la cadena de firma, siga estos pasos:

  1. Recupere todos los encabezados del recurso que comiencen por x-ms-, incluido el encabezado x-ms-date.

  2. Convierta cada nombre de encabezado HTTP a minúsculas.

  3. Ordene los encabezados lexicográficamente por nombres de encabezado, en orden ascendente. Tenga en cuenta que cada encabezado puede aparecer una sola vez en la cadena.

  4. Expanda la cadena reemplazando los espacios de separación en blanco por un solo espacio.

  5. Recorte los espacios en blanco alrededor del carácter de dos puntos en el encabezado.

  6. Por último, anexe un carácter de nueva línea a cada encabezado con formato canónico en la lista resultante. Construya la cadena CanonicalizedHeaders concatenando todos los encabezados de esta lista en una sola cadena.

La parte CanonicalizedResource de la cadena de firma representa el recurso de servicios de almacenamiento que constituye el destino de la solicitud. Cualquier parte de la cadena CanonicalizedResource derivada del URI del recurso debe codificarse exactamente tal como está en el URI.

La cadena CanonicalizedResource admite dos formatos:

  • Un formato que admite la autenticación Clave compartida para la versión 19-09-2009 de los servicios Blob y Cola, y para la versión 14-02-2014 del servicio Archivo.

  • Un formato que admite Shared Key y Shared Key Lite para todas las versiones del servicio Tabla, y Shared Key Lite para la versión 2009-09-19 de los servicios Blob y Cola. Este formato es idéntico al utilizado con versiones anteriores de los servicios de almacenamiento.

Para obtener ayuda acerca cómo construir el URI para el recurso al que está obteniendo acceso, vea uno de los temas siguientes:

noteNota
Si está realizando la autenticación en el emulador de almacenamiento, el nombre de la cuenta aparecerá dos veces en la cadena CanonicalizedResource. Este comportamiento es el esperado. Si está realizando la autenticación en los servicios de almacenamiento de Windows Azure, el nombre de la cuenta solo aparecerá una vez en la cadena CanonicalizedResource.

Formato Shared Key en la versión 2009-09-19

Este formato admite la autenticación Clave compartida para la versión 19-09-2009 de los servicios Blob y Cola, y para la versión 14-02-2014 del servicio Archivo. Construya la cadena CanonicalizedResource en este formato de la manera siguiente:

  1. A partir de una cadena vacía (""), anexe una barra diagonal (/), seguida del nombre de la cuenta a la que pertenece el recurso al que se va a tener acceso.

  2. Anexe la ruta de acceso URI codificada del recurso, sin ningún parámetro de consulta.

  3. Recupere todos los parámetros de consulta del URI de recurso, incluido el parámetro comp si existe.

  4. Convierta todos los nombres de parámetro a minúsculas.

  5. Ordene los parámetros de consulta lexicográficamente por nombres de parámetro, en orden ascendente.

  6. Extraiga de la dirección URL el nombre y el valor de cada uno de los parámetros de consulta.

  7. Anexe el nombre y el valor de cada uno de los parámetros de consulta a la cadena con el formato siguiente, asegurándose de incluir los dos puntos (:) entre el nombre y el valor:

    parameter-name:parameter-value

  8. Si un parámetro de consulta tiene más de un valor, ordene todos los valores lexicográficamente y, a continuación, inclúyalos en una lista separada por comas:

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

  9. Anexe un carácter de nueva línea (\n) después de cada par nombre-valor.

Aplique las reglas siguientes para construir la cadena de recurso con formato canónico:

  • Evite utilizar el carácter de nueva línea (\n) en los valores para los parámetros de consulta. Si es imprescindible hacerlo, asegúrese de que no afecte al formato de la cadena de recurso con formato canónico.

  • Evite el uso de comas en los valores de los parámetros de consulta.

A continuación se muestran algunos ejemplos que muestran la parte CanonicalizedResource de la cadena de firma, tal como se puede construir a partir de un URI de solicitud determinado:


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

Formato del servicio Tabla y Shared Key Lite en la versión 2009-09-19

Este formato admite Clave compartida y Clave compartida ligera para todas las versiones del servicio Tabla, y Clave compartida ligera para la versión 19-09-2009 de los servicios Blob y Cola, y para la versión 14-02-2014 del servicio Archivo. Este formato es idéntico al utilizado con versiones anteriores de los servicios de almacenamiento. Construya la cadena CanonicalizedResource en este formato de la manera siguiente:

  1. A partir de una cadena vacía (""), anexe una barra diagonal (/), seguida del nombre de la cuenta a la que pertenece el recurso al que se va a tener acceso.

  2. Anexe la ruta de acceso URI codificada del recurso. Si el URI de solicitud hace referencia a un componente del recurso, anexe la cadena de consulta adecuada. La cadena de consulta debe incluir el signo de interrogación y el parámetro comp (por ejemplo, ?comp=metadata). No se debe incluir ningún otro parámetro en la cadena de consulta.

Para codificar la firma, llame al algoritmo HMAC-SHA256 en la cadena de firma codificada mediante UTF-8 y codifique el resultado como Base64. Utilice el formato siguiente (mostrado como pseudocódigo):

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

Vea también

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft