Shared Access SignatureSolution ·
I’ve been spinning by head around to understand how to use this Azure Storage concept for quite a while, so I’ve decided to share my findings.
The most useful web resource I found was this blog entry. Here I’m gona give a less API-driven approach, which is faster as long as you know which containers / blobs you want to share in advance.
What is shared access signature good for?
The primary way to authenticate is to use the primary or secondary access keys. This method works fine, but it has three major drawbacks:
- It gives full access (read & write)
- It gives access to the entire storage account (table, queue & blobs).
- The only way to revoke access is to regenerate the key, in which case, everybody using it will be denied access.
Basically, it’s not very granular. On top of that, the key must be passed in an HTTP header, which isn’t browser friendly.
Shared Access Signature is an alternative way to authenticate against Azure Storage. As far as I know, it’s only useful for blobs. It’s granular, since it can go to the blob level to grant permissions, permissions are also more granular (read, write, list, delete) and the revocation can be automatic (duration) or done on each share access.
How can I use it?
The easiest way to quickly can a hang of it is to go to https://myazurestorage.com/. Now this site looks pretty dodgy but it actually belongs to the Windows Azure team, so you can feel free to enter your credentials in.
First thing, you enter the storage account name and the primary key (actually, the secondary works as well).
You can then go to the blobs tab. If you don’t already have a container, you can create one there. What I’m going to do here is to give read access to the entire container named content. I select the Manage Policies menu option on the container menu.
There’s a dialog window popping. I’m going to create a new policy for that container, so I click Add Policy:
I then fill the policies as follow:
Basically, I’m creating a policy named “Read”, starting today, ending in 2020 giving read permission. I click OK. I then select the Share menu option on the container menu.
Another dialog window pops. I select the policy I just created (Read) and click the Get URL button:
The URL looks something like this:
If we concentrate on the query string, it contains three components:
- sr, the resource, here c which stands for container. If we shared a blob, it would have been b.
- si, the policy.
- sig, the signature
I can then use the following code to access the blob container:
var credentials =
CloudBlobClient blobClient = new CloudBlobClient(
new Uri(".blob.core.windows.net")'>http://<account name>.blob.core.windows.net"),
var container = blobClient.GetContainerReference("content");
var list = container.ListBlobs();
foreach (CloudBlob blob in list)
I can revoke access to the container by changing the policy.
How does that work?
Basically when you click the Get URL button, Azure does spit out a signature and remembers it. So this URL is good forever, although the policy underneath can change.
We can also share the container directly, without using a policy, but the URL generated would contain the policy itself, ie the start time, end time, etc. . It is therefore less secure since if this URL becomes compromise, there is no way to revoke access. For this reason, the API limits the exposure time to an hour: we can’t give access for more than an hour this way.
Hope that gave shade some lights on the issue of shared access signature, have fun!