Autorizzare con chiave condivisa

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

Importante

Per una sicurezza ottimale, Microsoft consiglia di usare l'ID Entra di Microsoft con identità gestite per autorizzare le richieste nei dati blob, code e tabelle, quando possibile. L'autorizzazione con l'ID e le identità gestite di Microsoft Entra offre sicurezza e facilità di utilizzo superiori rispetto all'autorizzazione con chiave condivisa. Per altre informazioni, vedere Autorizzare con Microsoft Entra ID. Per altre informazioni sulle identità gestite, vedere Informazioni sulle identità gestite per le risorse di Azure.

Per le risorse ospitate all'esterno di Azure, ad esempio le applicazioni locali, è possibile usare le identità gestite tramite Azure Arc. Ad esempio, le app in esecuzione nei server abilitati per Azure Arc possono usare le identità gestite per connettersi ai servizi di Azure. Per altre informazioni, vedere Eseguire l'autenticazione con le risorse di Azure con i server abilitati per Azure Arc.

Per gli scenari in cui vengono usate le firme di accesso condiviso, Microsoft consiglia di usare una firma di accesso condiviso di delega utente. Una firma di accesso condiviso della delega utente è protetta con le credenziali di Microsoft Entra anziché la chiave dell'account. Per informazioni sulle firme di accesso condiviso, vedere Creare una firma di accesso condiviso di delega utente.

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

• Chiave condivisa per BLOB, code e servizi file. Usare lo schema di autorizzazione con 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 con chiave condivisa per effettuare richieste al servizio tabelle usando l'API REST. L'autorizzazione con 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 Lite. Usare lo schema di autorizzazione Shared Key Lite per effettuare richieste nei servizi BLOB, code, tabelle e file. Shared Key Lite non è supportato per i BLOB di pagine Premium.

  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 Shared Key Lite per effettuare richieste nei servizi BLOB e code senza aggiornare la stringa di firma.

Una richiesta autorizzata richiede due intestazioni: l'intestazione Date o x-ms-date e l'intestazione Authorization. Le sezioni seguenti descrivono come costruire queste intestazioni.

Importante

Archiviazione di Azure supporta sia HTTP che HTTPS, ma è consigliabile usare HTTPS.

Nota

Un contenitore o un BLOB può essere reso disponibile per l'accesso pubblico impostando le autorizzazioni di un contenitore. Per altre informazioni, vedere Gestire l'accesso alle risorse di archiviazione di Azure. È possibile rendere disponibile un contenitore, un BLOB, una coda o una tabella per l'accesso firmato tramite una firma di accesso condiviso; una firma di accesso condiviso è autorizzata tramite un meccanismo diverso. Per altri dettagli, vedere Delegare l'accesso con una firma di accesso condiviso.

Specifica dell'intestazione Date

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 http/HTTPS standard Date. Se nella richiesta vengono specificate entrambe le intestazioni, il valore di x-ms-date viene utilizzato come ora di creazione della richiesta.

I servizi di archiviazione assicurano che una richiesta non sia superiore a 15 minuti dal momento in cui raggiunge il servizio. Questo protegge da determinati attacchi di sicurezza, inclusi attacchi di riproduzione. Quando questo controllo ha esito negativo, il server restituisce il codice di risposta 403 (Accesso negato).

Nota

L'intestazione x-ms-date viene fornita perché alcune librerie client HTTP e proxy impostano automaticamente l'intestazione Date e non offrono allo sviluppatore la possibilità di leggerne il valore per includerlo nella richiesta autorizzata. Se si imposta x-ms-date, costruire la firma con un valore vuoto per l'intestazione Date.

Specifica dell'intestazione autorizzazione

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 o su un contenitore, UN BLOB, una coda o una 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 per l'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) costruito dalla richiesta e calcolato usando l'algoritmo SHA256 e quindi codificato tramite la codifica Base64.

Nota

È possibile richiedere una risorsa che risiede sotto un account diverso, se tale risorsa è accessibile pubblicamente.

Le sezioni seguenti descrivono come costruire l'intestazione Authorization.

Costruzione della stringa di firma

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

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

• 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 un'intestazione è duplicata, 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 di intestazione. Queste intestazioni possono essere vuote se non vengono specificate come parte della richiesta; in tal caso, è necessario solo il carattere di nuova riga.

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

  È accettabile specificare sia x-ms-date che Date; in questo caso, il servizio usa il valore di x-ms-date.

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

• Tutti i caratteri di nuova riga (\n) visualizzati sono obbligatori all'interno della stringa di firma.

• La stringa di firma include intestazioni canoniche e stringhe di risorse canoniche. La canonizzazione di queste stringhe li inserisce in un formato standard riconosciuto da Archiviazione di Azure. Per informazioni dettagliate sulla creazione delle stringhe CanonicalizedHeaders e CanonicalizedResource che costituiscono 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 della chiave condivisa per una richiesta rispetto alla versione 2009-09-19 e successive del servizio BLOB o coda e alla 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;  

Importante

Nella versione corrente, il campo Content-Length deve essere una stringa vuota se la lunghezza del contenuto della richiesta è zero. Nella versione 2014-02-14 e precedenti, la lunghezza del contenuto è stata inclusa anche se zero. Per altre informazioni sul comportamento precedente, vedere di seguito.

Nell'esempio seguente viene illustrata una stringa di firma per un'operazione di get blob di . 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  

L'interruzione di questa riga per riga 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*/  

Codificare quindi questa stringa usando l'algoritmo HMAC-SHA256 sulla stringa di firma con codifica UTF-8, costruire l'intestazione Authorization e aggiungere l'intestazione alla richiesta. L'esempio seguente illustra l'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 di Authorization esistenti per usare Shared Key Lite anziché Shared Key. Il formato di firma richiesto da Shared Key Lite è identico a quello richiesto per la chiave condivisa per le versioni dei servizi BLOB e code precedenti al 2009-09-19.

Importante

Se si accede alla posizione secondaria in un account di archiviazione per cui è abilitata la replica geografica di accesso in lettura (RA-GRS), non includere la designazione -secondary nell'intestazione dell'autorizzazione. Ai fini dell'autorizzazione, il nome dell'account è sempre il nome della posizione primaria, anche per l'accesso secondario.

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 parte Content-Length del 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 nel 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

Il StringToSign viene costruito nel modo seguente:

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, il StringToSign deve 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 con 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 La chiave condivisa nel servizio tabelle è lo stesso per tutte le versioni.

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

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

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

Nota

A partire dalla versione 2009-09-19, il servizio tabelle richiede che tutte le chiamate REST includano le intestazioni DataServiceVersion e MaxDataServiceVersion. Per altre informazioni, vedere Impostazione delle intestazioni della versione del servizio dati OData.

Blob, coda e servizi file (autorizzazione Shared Key Lite)

È possibile usare l'autorizzazione Shared Key Lite per autorizzare una richiesta effettuata in base alla versione 2009-09-19 e successive dei servizi BLOB e code e alla versione 2014-02-14 e successive dei servizi file. Shared Key Lite non è supportato per i BLOB di pagine Premium.

La stringa di firma per Shared Key Lite è identica alla stringa di firma necessaria per l'autorizzazione con 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 nel servizio BLOB o coda, 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 di put BLOB . Si noti che la riga di 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  

Codificare quindi questa stringa usando l'algoritmo HMAC-SHA256 sulla stringa di firma con codifica UTF-8, costruire l'intestazione Authorization e aggiungere l'intestazione alla richiesta. L'esempio seguente illustra l'intestazione Authorization per la stessa operazione:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Servizio tabelle (autorizzazione Shared Key Lite)

È 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 usando Shared Key Lite, usare il formato seguente:

StringToSign = Date + "\n"
               CanonicalizedResource  

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

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

Codificare quindi questa stringa usando l'algoritmo HMAC-SHA256, costruire l'intestazione Authorization e quindi aggiungere l'intestazione alla richiesta. L'esempio seguente illustra l'intestazione Authorization per la stessa operazione:

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

Costruzione della stringa di intestazioni canoniche

Per costruire la parte CanonicalizedHeaders della stringa di firma, seguire questa procedura:

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

2. Convertire ogni nome di intestazione HTTP in lettere minuscole.

3. Ordinare le intestazioni in modo lessicografico in base al nome dell'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 uno spazio singolo.

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. Aggiungere infine un carattere di nuova riga a ogni intestazione canonica nell'elenco risultante. Costruisci la stringa CanonicalizedHeaders concatenando tutte le intestazioni in questo elenco in una singola stringa.

Di seguito è riportato un esempio di stringa di intestazioni canoniche:

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

Nota

Prima della versione del servizio 2016-05-31, le intestazioni con valori vuoti venivano omesse dalla stringa di firma. Questi sono ora rappresentati in CanonicalizedHeaders immediatamente dopo il carattere due punti con la nuova riga di terminazione.

Costruzione della stringa di risorsa canonica

La CanonicalizedResource parte della stringa di firma rappresenta la risorsa dei servizi di archiviazione di destinazione della richiesta. Qualsiasi parte della stringa CanonicalizedResource derivata dall'URI della risorsa deve essere codificata esattamente come si trova nell'URI.

Esistono due formati supportati per la stringa CanonicalizedResource:

• Formato che supporta l'autorizzazione con 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.

• Formato che supporta Shared Key e Shared Key Lite per tutte le versioni del servizio tabelle e Shared Key Lite per la versione 2009-09-19 e successive dei servizi BLOB e code. 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

Importante

Se l'account di archiviazione viene replicato con la replica geografica di accesso in lettura (RA-GRS) e si accede a una risorsa nella posizione secondaria, non includere la designazione –secondary nella stringa CanonicalizedResource. L'URI della risorsa usato nell'URI della stringa CanonicalizedResource deve essere l'URI della risorsa nella posizione primaria.

Nota

Se si sta autorizzando l'emulatore di archiviazione, il nome dell'account verrà visualizzato due volte nella stringa CanonicalizedResource. Questo è previsto. Se si autorizzano i servizi di archiviazione di Azure, il nome dell'account verrà visualizzato una sola volta nella stringa CanonicalizedResource.

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

Questo formato supporta l'autorizzazione con chiave condivisa per la versione 2009-09-19 e versioni successive dei servizi BLOB e code e la versione 2014-02-14 e versioni successive dei servizi file. Costruire la stringa CanonicalizedResource in questo formato come indicato di seguito:

1. A partire da una stringa vuota (""), aggiungere una barra (/), seguita dal nome dell'account proprietario della risorsa a cui si accede.

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. Convertire tutti i nomi dei parametri in lettere minuscole.

5. Ordinare i parametri di query in modo lessicografico in base al nome del parametro, in ordine crescente.

6. Decodificare url per ogni nome e valore del parametro di query.

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

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

   parameter-name:parameter-value

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

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

Tenere presenti le regole seguenti per costruire la stringa di risorse canonica:

• Evitare di usare il carattere di nuova riga (\n) nei valori per i parametri di query. Se deve essere usato, assicurarsi che non influisca sul formato della stringa di risorse canonica.

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

Ecco alcuni esempi che mostrano la parte CanonicalizedResource 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 shared Key Lite e servizio tabelle per il 2009-09-19 e versioni successive

Questo formato supporta Shared Key and Shared Key Lite per tutte le versioni del servizio tabelle e Shared Key Lite per la versione 2009-09-19 e successive dei servizi BLOB e code e versione 2014-02-14 e successive del servizio file. Questo formato è identico a quello usato con le versioni precedenti dei servizi di archiviazione. Costruire la stringa CanonicalizedResource in questo formato come indicato di seguito:

1. A partire da una stringa vuota (""), aggiungere una barra (/), seguita dal nome dell'account proprietario della risorsa a cui si accede.

2. Aggiungere il percorso URI codificato della risorsa. Se l'URI della richiesta punta a 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). Nella stringa di query non devono essere inclusi altri parametri.

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 Base64. Si noti che è anche necessario decodificare la chiave dell'account di archiviazione in Base64. Usare il formato seguente (illustrato come pseudocodice):

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

Vedere anche

• 'API REST del servizio BLOB
• 'API REST del servizio di accodamento
• api REST del servizio tabelle
• REST di Servizi di archiviazione