Grant limited access to your Azure Storage BLOBS using Shared Access Signatures (SAS)

Grant limited access to your Azure Storage BLOBS using Shared Access Signatures (SAS)

My client has the requirement that BLOB’s be placed on a speedy, durable, scalable & highly available cloud storage platform and accessed via the public via a dropdown menu on their corporate web site where any anonymous could download the BLOB files.  The metadata for the BLOBs would be stored in a SharePoint environment and accessed via web services.

The tricky part of their requirement is that they wanted the link to expire after a certain amount of time due to the fact that they wanted to try and avoid (or at least make it harder) having people keep the files on their own systems, serving them up somewhere else to download and having cached or not up-to-date BLOB file URL links.

This is where I started looking at (with the direction of some good Microsoft folks) using Microsoft Azure Storage in conjunction with shared access signatures (SAS).

This shared access signature is a special URI that will point to my storage BLOB that I want to be download and have special tokens that contain a special set of query parameters such as how long the link is valid, an example of the key is as follows:

Shared access signatures should allow me to grant limited access to the BLOB objects in my client’s storage account anonymously, without exposing their account key for the anonymous users accessing the files from their Corporate Web Site.

The tokens/parameters that would be relevant to me are as follows:

  • Service version A required parameter that specifies the storage service version to use to authenticate the request.
  • Start time. This is the time at which the SAS becomes valid. The start time for a shared access signature is optional. If a start time is omitted, the SAS is effective immediately. The start time must be expressed in UTC (Coordinated Universal Time), with a special UTC designator (“Z”), for example 1994-11-05T13:15:30Z.
  • Expiry time. This is the time after which the SAS is no longer valid. Best practices recommend that you either specify an expiry time for a SAS, or associate it with a stored access policy. The expiry time must be expressed in UTC (Coordinated Universal Time), with a special UTC designator (“Z”), for example 1994-11-05T13:15:30Z (see more below).
  • Permissions. The permissions specified on the SAS indicate what operations the client can perform against the storage resource using the SAS. Available permissions differ for an account SAS and a service SAS.
  • Protocol. An optional parameter that specifies the protocol permitted for a request. Possible values are both HTTPS and HTTP (https,http), which is the default value, or HTTPS only (https). Note that HTTP only is not a permitted value.
  • Signature. The signature is constructed from the other parameters specified as part token and then encrypted. It’s used to authenticate the SAS.

The idea is that when the user accesses the dropdown of the type of BLOB they want to download, I call a custom web service that will generate the SAS URI and serve it up to the user to download the file.

As soon as I have my team develop this, I will create a post to talk about how we did it.

View more information about SAS here: https://docs.microsoft.com/en-us/azure/storage/storage-dotnet-shared-access-signature-part-1

Leave a Reply

Your email address will not be published. Required fields are marked *