Autorizzare con la chiave condivisa

Ogni richiesta eseguita su un servizio di archiviazione deve essere autorizzata, a meno che la richiesta non sia relativa a una risorsa BLOB o contenitore resa disponibile per l'accesso pubblico o firmato. Un'opzione per l'autorizzazione di una richiesta consiste nell'usare la chiave condivisa, descritta in questo articolo.

I servizi BLOB, coda, tabelle e file supportano gli schemi di autorizzazione della chiave condivisa seguenti per la versione 2009-09-19 e successive (per BLOB, coda e servizio tabelle) e versione 2014-02-14 e successive (per il servizio file):

• Chiave condivisa per i servizi BLOB, di accodamento e file. Usare lo schema di autorizzazione chiave condivisa per effettuare richieste per i servizi BLOB, coda e file. L'autorizzazione con chiave condivisa nella versione 2009-09-19 e successive supporta una stringa di firma aumentata per la sicurezza avanzata e richiede l'aggiornamento del servizio per autorizzare l'uso di questa firma aumentata.

• Chiave condivisa per il servizio tabelle. Usare lo schema di autorizzazione chiave condivisa per effettuare richieste al servizio tabelle usando l'API REST. L'autorizzazione della chiave condivisa per il servizio tabelle nella versione 2009-09-19 e successive usa la stessa stringa di firma delle versioni precedenti del servizio tabelle.

• Chiave condivisa versione Lite. Usare lo schema di autorizzazione Shared Key Lite per effettuare richieste per i servizi BLOB, coda, tabella e file.

  Per la versione 2009-09-19 e successive dei servizi BLOB e code, l'autorizzazione Shared Key Lite supporta l'uso di una stringa di firma identica a quella supportata per la chiave condivisa nelle versioni precedenti dei servizi BLOB e code. È quindi possibile usare Chiave condivisa versione Lite per effettuare richieste nei servizi BLOB e di accodamento senza aggiornare la stringa di firma.

Una richiesta autorizzata richiede due intestazioni: l'intestazione Date o x-ms-date e l'intestazione Authorization . Nelle sezioni seguenti viene descritto come creare queste intestazioni.

Specifica dell'intestazione Data

Tutte le richieste autorizzate devono includere il timestamp UTC (Coordinated Universal Time) per la richiesta. È possibile specificare il timestamp nell'intestazione x-ms-date o nell'intestazione Date HTTP/HTTPS standard. Se entrambe le intestazioni sono specificate nella richiesta, il valore di x-ms-date viene usato come ora di creazione della richiesta.

I servizi di archiviazione garantiscono che non trascorrano più di 15 minuti prima che una richiesta raggiunga il servizio. Si tratta di una misura di sicurezza contro eventuali intrusioni, inclusi gli attacchi di tipo replay. Se questo controllo ha esito negativo, il server restituisce il codice di risposta 403 (Accesso negato).

Specifica dell'intestazione Authorization

Una richiesta autorizzata deve includere l'intestazione Authorization . Se questa intestazione non è inclusa, la richiesta è anonima e ha esito positivo solo su un contenitore o un BLOB contrassegnato per l'accesso pubblico oppure su un contenitore, blob, coda o tabella per cui è stata fornita una firma di accesso condiviso per l'accesso delegato.

Per autorizzare una richiesta, è necessario firmare la richiesta con la chiave per l'account che effettua la richiesta e passare tale firma come parte della richiesta.

Il formato dell'intestazione Authorization è il seguente:

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

dove SharedKey o SharedKeyLite è il nome dello schema di autorizzazione, AccountName è il nome dell'account che richiede la risorsa e Signature è un codice HMAC (Hash-based Message Authentication Code) creato dalla richiesta e calcolato usando l'algoritmo SHA256 e codificato con Base64.

Nelle sezioni seguenti viene descritto come creare l'intestazione Authorization.

Costruzione della stringa di firma

Il modo in cui si costruisce la stringa di firma dipende dal servizio e dalla versione in base alla quale si sta autorizzando e a quale schema di autorizzazione si sta usando. Quando si crea una stringa di firma, tenere presente quanto segue:

• La parte VERB della stringa è il verbo HTTP, ad esempio GET o PUT e deve essere scritta in maiuscolo.

• Per l'autorizzazione della chiave condivisa per i servizi BLOB, coda e file, ogni intestazione inclusa nella stringa di firma può essere visualizzata una sola volta. Se sono presenti intestazioni duplicate, il servizio restituisce il codice di stato 400 (Richiesta non valida).

• I valori di tutte le intestazioni HTTP standard devono essere inclusi nella stringa nell'ordine indicato nel formato della firma, senza i nomi delle intestazioni. Queste intestazioni possono essere vuote se non vengono specificate come parte della richiesta; in tal caso, è necessario solo il carattere di nuova riga.

• Se l'intestazione x-ms-date viene specificata, è possibile ignorare l'intestazione Date , indipendentemente dal fatto che sia specificata nella richiesta e specificare semplicemente una riga vuota per la Date parte della stringa della firma. In questo caso, seguire le istruzioni riportate nella sezione Costruzione della stringa delle intestazioni canoniche per l'aggiunta dell'intestazione x-ms-date .

  È accettabile specificare sia che x-ms-dateDate. In questo caso, il servizio usa il valore di x-ms-date.

• Se l'intestazione x-ms-date non viene specificata, specificare l'intestazione Date nella stringa di firma, senza includere il nome dell'intestazione.

• Tutti i caratteri di nuova riga (\n) mostrati sono obbligatori nella stringa di firma.

• La stringa di firma include intestazioni in forma canonica e stringhe di risorsa in forma canonica. Con la canonicalizzazione, tali stringhe acquisiscono un formato standard riconosciuto da Archiviazione di Azure. Per informazioni dettagliate sulla creazione delle stringhe CanonicalizedHeaders e CanonicalizedResource che compongono parte della stringa di firma, vedere le sezioni appropriate più avanti in questo argomento.

BLOB, code e servizi file (autorizzazione con chiave condivisa)

Per codificare la stringa di firma basata su Chiave condivisa per una richiesta nella versione 2009-09-19 e successive del servizio BLOB o di accodamento e nella versione 2014-02-14 e successive del servizio file, usare il formato seguente:

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;  

Nell'esempio seguente viene illustrata una stringa di firma per un'operazione Get BLOB . Se non è presente alcun valore di intestazione, viene specificato solo il carattere di nuova riga.

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  

Se lo si scompone riga per riga si mostra ogni parte della stessa stringa:

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

In seguito, codificare questa stringa usando l'algoritmo HMAC-SHA256 sulla stringa di firma con codifica UTF-8, creare l'intestazione Authorization e aggiungere l'intestazione alla richiesta. Nell'esempio seguente viene illustrata intestazione Authorization per la stessa operazione:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Per usare l'autorizzazione con chiave condivisa con la versione 2009-09-19 e successive dei servizi BLOB e code, è necessario aggiornare il codice per usare questa stringa di firma aumentata.

Se si preferisce eseguire la migrazione del codice alla versione 2009-09-19 o successiva dei servizi BLOB e code con il minor numero possibile di modifiche, è possibile modificare le intestazioni esistenti Authorization in modo da usare Shared Key Lite anziché Shared Key. Il formato della firma richiesto da Chiave condivisa versione Lite è identico a quello richiesto da Chiave condivisa nelle versioni dei servizi di accodamento e BLOB precedenti alla 2009-09-19.

Intestazione Content-Length nella versione 2014-02-14 e precedenti

Quando si usa la versione 2014-02-14 o precedente, se Content-Length è zero, impostare la Content-Length parte di StringToSign su 0. In genere si tratta di una stringa vuota.

Ad esempio, per la richiesta seguente, il valore dell'intestazione Content-Length viene incluso in StringToSign anche quando è zero.

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

L'oggetto StringToSign viene costruito come segue:

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

Mentre nelle versioni successive a 2014-02-14, deve StringToSign contenere una stringa vuota per 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

Servizio tabelle (autorizzazione con chiave condivisa)

È necessario usare l'autorizzazione di chiave condivisa per autorizzare una richiesta effettuata al servizio tabelle se il servizio usa l'API REST per effettuare la richiesta. Il formato della stringa di firma per l'autenticazione Chiave condivisa nel servizio tabelle è lo stesso per tutte le versioni.

La stringa di firma chiave condivisa per una richiesta per il servizio tabelle è leggermente diversa da quella per una richiesta rispetto al servizio BLOB o coda, in quanto non include la CanonicalizedHeaders parte della stringa. Inoltre, in questo caso l'intestazione Date non è mai vuota anche se la richiesta imposta l'intestazione x-ms-date. Se la richiesta imposta x-ms-date, lo stesso valore viene usato come valore dell'intestazione Date.

Per codificare la stringa di firma per una richiesta nel servizio tabelle effettuata usando l'API REST, usare il formato seguente:

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

Servizi BLOB, code e file (autorizzazione Shared Key Lite)

È possibile usare l'autorizzazione Shared Key Lite per autorizzare una richiesta effettuata sulla versione 2009-09-19 e versioni successive dei servizi BLOB e code e versione 2014-02-14 e successive dei servizi file.

La stringa di firma per Shared Key Lite è identica alla stringa di firma necessaria per l'autorizzazione della chiave condivisa nelle versioni dei servizi BLOB e code precedenti al 2009-09-19. Pertanto, se si vuole eseguire la migrazione del codice con il minor numero di modifiche apportate alla versione 2009-09-19 dei servizi BLOB e code, è possibile modificare il codice in modo da usare Shared Key Lite, senza modificare la stringa di firma stessa. Usando Shared Key Lite, non si otterrà la funzionalità di sicurezza avanzata fornita usando la chiave condivisa con la versione 2009-09-19 e successive.

Per codificare la stringa di firma per una richiesta effettuata nel servizio BLOB o di accodamento, usare il formato seguente:

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

Nell'esempio seguente viene illustrata una stringa di firma per un'operazione Put BLOB . Si noti che la riga dell'intestazione Content-MD5 è vuota. Le intestazioni visualizzate nella stringa sono coppie nome-valore che specificano valori di metadati personalizzati per il nuovo 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  

In seguito, codificare questa stringa usando l'algoritmo HMAC-SHA256 sulla stringa di firma con codifica UTF-8, creare l'intestazione Authorization e aggiungere l'intestazione alla richiesta. Nell'esempio seguente viene illustrata intestazione Authorization per la stessa operazione:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Servizio tabelle (autorizzazione Lite chiave condivisa)

È possibile usare l'autorizzazione Shared Key Lite per autorizzare una richiesta effettuata su qualsiasi versione del servizio tabelle.

Per codificare la stringa di firma per una richiesta nel servizio tabelle effettuata usando Chiave condivisa versione Lite, usare il formato seguente:

StringToSign = Date + "\n"
               CanonicalizedResource  

Nell'esempio seguente viene illustrata una stringa di firma per un'operazione table di Create.

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

In seguito, codificare questa stringa usando l'algoritmo HMAC-SHA256, creare l'intestazione Authorization e aggiungere l'intestazione alla richiesta. Nell'esempio seguente viene illustrata intestazione Authorization per la stessa operazione:

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

Costruzione della stringa delle intestazioni canoniche

Per creare la parte CanonicalizedHeaders della stringa di firma, effettuare le operazioni seguenti:

1. Recuperare tutte le intestazioni per la risorsa che iniziano con x-ms-, inclusa l'intestazione x-ms-date.

2. Scrivere tutti i nomi delle intestazioni HTTP in caratteri minuscoli.

3. Ordinare le intestazioni in modo lessicografico per nome di intestazione, in ordine crescente. Ogni intestazione può essere visualizzata una sola volta nella stringa.

   Nota

   L'ordinamento lessicografico potrebbe non coincidere sempre con l'ordinamento alfabetico convenzionale.

4. Sostituire qualsiasi spazio vuoto lineare nel valore dell'intestazione con un singolo spazio.

Gli spazi vuoti lineari includono ritorno a capo/avanzamento riga (CRLF), spazi e schede. Per informazioni dettagliate , vedere RFC 2616, sezione 4.2 . Non sostituire spazi vuoti all'interno di una stringa tra virgolette.

1. Tagliare gli spazi vuoti intorno ai due punti nell'intestazione.

2. Infine, aggiungere un carattere di nuova riga a ogni intestazione in forma canonica nell'elenco risultante. Creare la stringa CanonicalizedHeaders concatenando tutte le intestazioni in questo elenco in una singola stringa.

Di seguito viene illustrato un esempio di stringa di intestazioni in forma canonica:

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

Costruzione della stringa di risorsa canonica

La parte CanonicalizedResource della stringa di firma rappresenta la risorsa dei servizi di archiviazione a cui è destinata la richiesta. Tutte le parti della stringa CanonicalizedResource che derivano dall'URI della risorsa devono essere codificate esattamente come nell'URI.

Due sono i formati supportati per la stringa CanonicalizedResource:

• Formato che supporta l'autorizzazione della chiave condivisa per la versione 2009-09-19 e successive dei servizi BLOB e code e per la versione 2014-02-14 e successive del servizio file.

• Un formato che supporta l'autenticazione Chiave condivisa e quella basata sulla versione Lite della Chiave condivisa per tutte le versioni del servizio tabelle e la versione Lite della Chiave condivisa per la versione 2009-09-19 e successive dei servizi di accodamento e BLOB. Questo formato è identico a quello usato con le versioni precedenti dei servizi di archiviazione.

Per informazioni sulla creazione dell'URI per la risorsa a cui si accede, vedere uno degli argomenti seguenti:

• Servizio BLOB: denominazione e riferimento a contenitori, BLOB e metadati

• Servizio di accodamento: indirizzamento delle risorse del servizio di accodamento

• Servizio tabelle: Indirizzamento delle risorse del servizio tabelle

• Servizio file: denominazione e riferimento a condivisioni, directory, file e metadati

Formato chiave condivisa per 2009-09-19 e versioni successive

Questo formato supporta l'autorizzazione della chiave condivisa per la versione 2009-09-19 e successive dei servizi BLOB e code e la versione 2014-02-14 e versioni successive dei servizi file. Creare la stringa CanonicalizedResource nel formato seguente:

1. Da una stringa vuota (""), aggiungere una barra (/), seguita dal nome dell'account proprietario della risorsa a cui si desidera accedere.

2. Aggiungere il percorso URI codificato della risorsa, senza parametri di query.

3. Recuperare tutti i parametri di query nell'URI della risorsa, incluso il parametro comp se esistente.

4. Scrivere tutti i nomi dei parametri in caratteri minuscoli.

5. Ordinare i parametri di query in modo lessicografico per nome di parametro, in ordine crescente.

6. Decodificare come URL il nome e il valore di ogni parametro di query.

7. Includere un carattere di nuova riga (\n) prima di ogni coppia nome-valore.

8. Aggiungere il nome e il valore di ogni parametro di query alla stringa nel formato seguente, assicurandosi di includere due punti (:) tra il nome e il valore:

   parameter-name:parameter-value

9. Se un parametro di query presenta più di un valore, ordinare tutti i valori in modo lessicografico, quindi includerli in un elenco separato da virgole:

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

Tenere presente le seguenti regole per la creazione della stringa di risorsa in forma canonica:

• Evitare di usare il carattere di nuova riga (\n) nei valori per i parametri di query. Se è necessario usarlo, assicurarsi che non influisca sul formato della stringa di risorsa in forma canonica.

• Evitare di usare virgole nei valori dei parametri di query.

Ecco alcuni esempi che mostrano la CanonicalizedResource parte della stringa di firma, perché può essere costruita da un URI di richiesta specificato:

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 del servizio Tabelle e Lite chiave condivisa per 2009-09-19 e versioni successive

Questo formato supporta l'autenticazione Chiave condivisa e Chiave condivisa versione Lite per tutte le versioni del servizio tabelle e Chiave condivisa versione Lite per la versione 2009-09-19 e successive dei servizi BLOB e di accodamento e per la versione 2014-02-14 e successive del servizio file. Questo formato è identico a quello usato con le versioni precedenti dei servizi di archiviazione. Creare la stringa CanonicalizedResource nel formato seguente:

1. Da una stringa vuota (""), aggiungere una barra (/), seguita dal nome dell'account proprietario della risorsa a cui si desidera accedere.

2. Aggiungere il percorso URI codificato della risorsa. Se l'URI della richiesta indirizza un componente della risorsa, aggiungere la stringa di query appropriata. La stringa di query deve includere il punto interrogativo e il parametro comp, ad esempio ?comp=metadata. Nessun altro parametro deve essere incluso nella stringa di query.

Codifica della firma

Per codificare la firma, chiamare l'algoritmo HMAC-SHA256 nella stringa di firma con codifica UTF-8 e codificare il risultato come Base 64. Si noti che è anche necessario decodificare la chiave dell'account di archiviazione in Base64. Usare il formato seguente (indicato come pseudocodice):

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

Vedi anche

• API REST del servizio BLOB
• API REST del servizio di accodamento
• API REST del servizio tabelle
• REST dei servizi di archiviazione