Implementing a platform for exchanging files on Windows Azure

In a somewhat interesting coincidence I’ve had two discussions in as many weeks with separate companies about how to provide a platform to allow exchanging files with customers of theirs on Windows Azure.

Both companies are in the media business albeit in different ways and they both needed to exchange large-ish files with customers, but the transfer had to be protected (the materials exchanged are paid for and contain private IP) and they should be simple to use to everyone, without the need for elaborate technical implementation.

Windows Azure provides all the capabilities required to implement such a platform easily and quickly –

• Blob storage is a natural place to store the files securely and cheaply.
• Shared Access Signatures provide an easy mechanism to enable time-limited access to these files
• Access Control Service provides an easy way to authenticate users using existing identities

At the most basic level – the file provider could store it on a Windows Azure Storage blob, Create a Shared Access Signature (SAS) that allows access to the file for a time-limited period and share that URL with the customer.

These steps can be automated and integrated into existing processes, for example ones used to produce the file by the provider or procure it by the customer.

Having said that, whilst shared access signature provide an easy way to access protected resources on Windows Azure Storage, that ease of access comes with reduced security level – anyone who gains access to the URL containing the SAS gains access to the resource.

For that reason I generally prefer to provide access to blobs rather than containers, for example, or at least consider how many resources exist within any one container accessible via shared access signature and – more importantly in my view – I always prefer SAS with a short validity period rather than a long one (I’d say measured in hours, if not minutes, rather than days).

So – taking this into consideration – how can one provide access to files over a longer period of time more securely whilst still leveraging SAS for easy of use?

One option, when humans are involved, is a self-service portal for generating a short-lived SAS by the consumer –

Taking this approach, when a file gets produced for a customer, or rights are being assigned, the rights are written to an Azure Table keyed on the identity of the user.

Using public identities such as Live, Google, Yahoo or Facebook to identify users makes it easier for them to access the system (they do not need to remember another set of credentials) as well as for the system developer as Azure provides seamless, out of the box, integration with these through the ACS.

When a user accesses the system using the agreed identity she see a list of all the resources she can access according to the information in the table and with the list the ability to generate a short lived SAS for resources she selects.

Doing so will produce the URLs with the SAS which can be used to access the resources and these can be delivered to the user through the UI or using email or something similar for increased security.

These process can be a one-time process or one that allows multiple accesses, depending on the requirement and the time frame in which the user can generate these URLs is governed by the information in the Azure Table (which would include an expiration date), they key is that using short lived URLs reduces the risk of these being compromised.

A similar approach can be taken in system-to-system scenario, where a secure web-service interface can be used to obtain the SAS urls, which can then be used to access the resources; this double-hop may seem wasteful at first, as the web service could be used to return the actual contents of the blob, but for large resources it is more efficient for the client to access them directly.

Admittedly there’s a bit more work involved in building these scenarios compared to simply generating and sending SAS’ as needed, but the amount of extra work is quite small, and the benefit in terms of increased security is quite substantial; as always – there’s a balance between effort and security, one that each project has to evaluate.