You probably giggled when you first heard this from your mentors and teachers, but they were right! Keeping your privates private is absolutely essential on the cloud.
Why is this important?
The best example I can think of, is keeping your Windows Azure Storage keys private. Embedding your storage keys in
Windows 8, Silverlight, Windows Phone or any type of redistributable application is the same as posting them on forums!
Failing to keep your Windows Azure Storage keys private puts all your data at risk.
Doing it Right
Providing access to Windows Azure Storage without compromising your whole Windows Azure Storage Account can be achieved by using the Valet Key Pattern described in Cloud Architecture Patterns by Bill Wilder.
The Valet Key Pattern
This pattern parallels with real world valet keys. These special keys give valets limited access so that they may complete their tasks without having full access. Consequently, valets can park your car without being able to look in the trunk.
If you want to learn more about the Valet Key pattern, I strongly recommend reading Revisiting Windows Azure Shared Access Signature
On Windows Azure, you can emulate these keys by using Shared Access Signatures. I have a good example of how to use a Shared Access Signature on my previous post about copying Blobs from one storage account to an other.
A Shared Access Signature is a URL that grants access rights to containers, blobs, queues, and tables. By specifying a Shared Access Signature, you can grant users who have the URL access to a specific resource for a specified period of time. You can also specify what operations can be performed on a resource that’s accessed via a Shared Access Signature. Supported operations include:
- Reading and writing page or block blob content, block lists, properties, and metadata
- Deleting, leasing, and creating a snapshot of a blob
- Listing the blobs within a container
- Adding, removing, updating, and deleting queue messages (in version 2012-02-12 and newer)
- Getting queue metadata, including the message count (in version 2012-02-12 and newer)
- Querying, adding, updating, deleting, and upserting table entities (in version 2012-02-12 and newer)
The Shared Access Signature URL query parameters incorporate all of the information necessary to grant controlled access to a storage resource. The URL query parameters specify the time interval over which the Shared Access Signature is valid, the permissions that it grants, the resource that is to be made available, and the signature that the storage services should use to authenticate the request.
Additionally, the Shared Access Signature URL can reference a stored access policy that provides an additional level of control over a set of signatures, including the ability to modify or revoke access to the resource if necessary. For more information on resource-level access policies, see Use a Stored Access Policy.
[More]
Consuming Windows Azure Storage From an App
Providing access to your Windows Azure Storage using Shared Access Signatures isn’t rocket science, but it takes a bit of extra work!
To accomplish this, you will need to implement a web service using your favorite technology (ASP.NET Web API/ ASMX, WCF…). The service will handle requests from your app and will return Shared Access Signature URLs that can be used to interact through REST with your Windows Azure Storage Account.
Creating a Shared Access Signature
To create a Shared Access Signature URL you will need a blob reference. Then you will need to define the Shared Access Blob Policy. It is used to enumerate the rights for the app that will be working with the generated URL.
The code below, takes the name of a blob and a period in minutes where the URL is valid. It builds an instance of Shared Access Blob Policy with the desired configurations. Then it generates the Shared Access Signature and appends it to the blob’s absolute URL.
The resulting URL can be used from a number of devices like phones, tables and even from watches!
{
var toDateTime = DateTime.UtcNow.AddMinutes(validityPeriodInMinutes);
var sharedAccessBlobPolicy = new SharedAccessBlobPolicy
{
Permissions = SharedAccessBlobPermissions.Read,
SharedAccessStartTime = null,
SharedAccessExpiryTime = new DateTimeOffset(toDateTime)
};
var cs = CloudConfigurationManager.GetSetting("csKey");
var account = CloudStorageAccount.Parse(cs);
var client = account.CreateCloudBlobClient();
var container = client.GetContainerReference("my-container-name");
var blockBlobReference = container.GetBlockBlobReference(blobname);
var sas = blockBlobReference.GetSharedAccessSignature(sharedAccessBlobPolicy);
return blockBlobReference.Uri.AbsoluteUri + sas;
}
More on Working With Windows Azure Storage
- Bill Wilders Blog
- Revisiting Windows Azure Shared Access Signature
- Cloud Architecture Patterns
- Architecture Patterns for Data Upload to Windows Azure
- Getting the Most out of Windows Azure Storage
- Copy Blobs With StartCopyFromBlob and Track its Progression Using CopyState
- Windows Azure Blob Storage Service – Migrating Blobs Between Accounts
- Save Money by Setting Cache-Control on Windows Azure Blobs
Alexandre Brisebois ☁ 