Shared Key authentication for Table service is the most secure method of authenticating against the Table service using the REST API. The method for generating an authentication key is similar to the method used for BLOBs (with a few subtle differences).
In order to generate a shared key, you need to canonicalize the HTTP request and then hash it using a SHA-56 algorithm, storing the hashed value in the Authorization header. The following value represents the Authorization header for a request, hashed using the Shared Key mechanism:
SharedKey devstoreaccount1:J5xkbSz7/7Xf8sCNY3RJIzyUEfnj1SJ3ccIBNpDzsq4=
The major difference between the shared key for the BLOB service (as well as the Queue service for that matter) and the Table service is that you don’t include canonicalized headers in the signature. The following code shows how you would generate the string prior to SHA-256 hashing:
unhashedString = VERB + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Date + "\n" + canonicalizedRequest;
Once you’ve generated the string, you can hash it and stuff it into the Authorization header.
Although you can use the Shared Key mechanism with the Table service, it can only be used with the REST API directly—the WCF Data Services client doesn’t support the Shared Key mechanism. Fortunately, the Table service also supports Shared Key Lite as an authentication mechanism (which is supported by the WCF Data Services client). Let’s take a look at that authentication mechanism.
The Shared Key Lite authentication mechanism for signing a request is similar to the Shared Key method. Like the Shared Key mechanism, it will canonicalize and hash the request using a SHA-256 algorithm, storing the result in the Authorization header. The following value represents the Authorization header for a request hashed using the Shared Key Lite mechanism:
SharedKeyLite devstoreaccount1:0c4bknVWVmQ+L1r5jCIYFiNDkSXHata8ZYW8mjQhPLo=
Although Shared Key Lite follows the same process of hashing a request and uses the same key to hash the request as the Shared Key mechanism, Shared Key Lite is a lighter and less secure mechanism. The Shared Key mechanism includes more data as part of the hash, meaning a hacker would have a better chance of tampering with the request when you’re using Shared Key Lite rather than Shared Key.
If you look back to listing 2, you can see that the request is signed prior to writing the Atom XML to the request body (at ). That means the XML isn’t part of the hash and can be tampered with.
If an HTTP request is intercepted within the Shared Access Signature time window, a hacker would be able to modify the request to create a table of a different type (such as a NastyHackerTable). The hacker would not be able to perform any other types of requests, however, because the hash prevents the HTTP verb from being tampered with.
If you’re using WCF Data Services to communicate with the Table service and your application runs purely within the data center, you can continue to use the Shared Key Lite mechanism. (To be honest, you don’t have a choice, as it’s the only authentication mechanism supported by the WCF Data Services client.)
If you’re using the REST API directly, and you have an application communicating with the Table service API outside of the Windows Azure data center, or you want the highest possible security, you should use the REST API directly with Shared Key authentication.
By now, you should have a good feel for storage accounts, the REST API, AtomPub, and which operations you can perform on a storage account using both the REST API directly and the StorageClient library. Now let’s look at how to perform CRUDy stuff (inserts, updates, and deletes—we’ll do querying later) in conjunction with the REST API and the StorageClient library.
