What is the best way to secure blobs in Windows Azure storage for a specific set of users. e.g I have a ASP.NET Web Site (intranet) on-premises with a back-end Windows Azure blob storage for large files. I like the idea of a signed URL for security for each individual blob but would this really work for a blob that will be there for a long time. (infinite?)
I need granular levels of security on the blob for only specific users (how do I achieve this easily with Blob Storage). *Note I believe I shouldn’t need the ACS. I want to achieve it using Policies and Signed URL’s if possible.
Second question, I assume I can also secure this data in the CDN in the same way, can someone confirm?
Thanks
Shared Access Policy with an infinite time work and privileges on the blob e.g. read work?
If you need the blob to be available to individual users longer than an hour, you must use a SAS policy that is attached to the container. However, since you can have at max 5 per container, it won’t scale well for many users. A SAS policy can have an expiry measured in years.
The more typical solution here is for a user to hit your website or service and you authenticate them in whatever manner you choose. When they actually wish to download the file, you should generate a 1-time SAS signature with a shorter expiry (not a policy). This scales well and prevents re-use by unauthorized users later in time. You also get benefit of serving from storage and not your web role.
Things get more complicated when you use CDN. So, while you can use SAS signature on CDN resource, they are not truly honored. That is, the unique URL is the key to the underlying resource. So, when you request a SAS secured blob, it will just pull it into CDN and serve it using that URI as key. It will then use the CDN caching policy (not SAS expiration) to serve going forward. This can lead to scenario where blob URI is set to expire in 10 mins, but CDN will cache that blob using same SAS signature for days depending on expiration policy. CDN will never contact storage again to validate. Hence, probably not a good idea to use this. Furthermore, since each CDN resource is keyed to URI, it also means that you would cache many copies of the same file (running up transaction and bandwidth charges) each time the SAS signature changed. Long story short, CDN and SAS don’t mix well.