Authorization
The authorization field is expressed in this way:Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
The authorization supports 2 schemes for calculating signatures, Shared Key or Shared Key Lite. The scheme you are using for authorization must be stated with either SharedKey or SharedKeyLite as the first thing in the header field.
The difference between the schemes are, Shared Key Lite is backward compatible with earlier versions of the Azure Storage API. I can't remember to have seen any example with Shared Key, I guess it is because it requires more effort to make it work.
Important!!! When using dates in authorization, these dates must be the same as x-ms-date, or else the authorisation will fail.
Shared key
Blob, Queue and File Storage signature is calculated one way, while Table Storage signature is calculated in another way.
Blob, Queue and File Storage:
StringToSign =
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;
Table Storage:
StringToSign =
Blob, Queue and File Storage:
StringToSign =
VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
Table Storage:
StringToSign =
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;
Table Storage:
StringToSign =
VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
Shared key Lite
Like Shared Keys, there is a difference in calculating the keys depending on what kind of storage is used:Blob, Queue and File Storage:
StringToSign =
VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
Table Storage:
StringToSign =
Date + "\n" +
CanonicalizedResource
When comparing the 2 schemes, it begins to make sense why most chose to use Shared Key Lite
Which parameter must be filled, depends heavily on context. E.g. Date, while it must be set in every Table request, there is some Blob requests where it must not be set.
CanonicalizedResource
When comparing the 2 schemes, it begins to make sense why most chose to use Shared Key Lite
Which parameter must be filled, depends heavily on context. E.g. Date, while it must be set in every Table request, there is some Blob requests where it must not be set.
Canonicalized Headers
Just take all the header starting with x-ms-, sort them and concatenate them separated by \n.
Exmaple(taken from the Azure Storage documentation):
x-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n
Canonicalized Resources
Canonicalized resources is form the following way:
Canonicalized resource = /account/resource
Example:
For this request
GET https://myaccount.table.core.windows.net/Tables HTTP/1.1
The canonicalized resource will be /myaccount/Tables
Query parameters must not be included. Unless you make following request(taken from documentation):
GET https://<account-name>.table.core.windows.net/?restype=service&comp=properties HTTP/1.1
Here the canonicalized resource will be /myaccount/?comp=properties
Calculating the signature
Here is the Azure Storage REST API documentation pretty weak. 2 things it misses are, when using HMAC you need to supply a key and a message. In context of making requests to the Azure Storage REST API, the key is either the Primary og Secondary key, which can be obtain from the Azure portal. The message is the StringToSign defined earlier in this post.
Also, the Primary and Secondary key which is found on the Azure portal are base64 encoded, you need to decode them, in order to be able to use them.
So what the documentation states as
Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))
Is in reality
Signature=Base64(HMAC-SHA256(UTF8(Debase64(key)),UTF8(StringToSign)))
Where key is either the Primary or Secondary key.
And this is all for Authorization.
