Azure file storage: authenticated direct downloads

0
votes

I have a solution built on ASP.Net MVC (hosted either on VM or Azure WebApp), Azure File Storage and with ASP.Net Identity Provider for authentication.

The solution involves a lot of uploading and downloading of files from the server.

Before a file is downloaded, some authentication must first take place on the server.

This is currently implemented in my solution as follows:

  1. Signed-in user clicks on download link/button and HTTP request is sent to server.
  2. ASP.Net MVC controller method authenticates and authorises the download for the specific user.
  3. The controller method downloads the file from file storage onto the server from Azure file storage
  4. The file is streamed to the logged in user from the server.

I have noticed from the above approach that it has the following drawbacks:

  • A significant amount of server resources is used up during the process, including memory, disk I/O, processing power.
  • It generates a lot of network traffic in and out of the web server.
  • The result of the above is that my solution requires a significantly larger pricing tier because of the above two points

Much of the above can be circumvented if I can somehow establish a direct download from File Storage to the client / user after the request has been authorised from the web server / controller method.

The solution I have come up with is to generate a SAS (shared access signature) on the requested file (with short lifespan) as soon as the request has been authorised, and then to redirect the client to the direct download URL with the SAS.

Is there any reason why I should not use this approach, or are there any better approaches available?

1
asp.net-mvcazureazure-storageazure-blob-storage

1 Answers

1
votes

The solution I have come up with is to generate a SAS (shared access signature) on the requested file (with short lifespan) as soon as the request has been authorised, and then to redirect the client to the direct download URL with the SAS.

I think it is a good approach. This approach overcomes all the shortcomings you mentioned.

Is there any reason why I should not use this approach, or are there any better approaches available?

Apart from keeping SAS short-lived (as you are already doing), there are a few things I could think of. See if they make sense to you:

  • Include IP Address ACLing in your SAS. This would prevent sharing of SAS URL by your users as the SAS URL will only work with the IP address defined in it.
  • Force download. You could override content-disposition header in your SAS so that the file is downloaded automatically instead of leaving it to the user to download the file.