Azure Shared Access Signatures To Restrict Access

Question

We are just starting to use Azure and I'm trying to get a handle on some security issues.

We are developing a web app that is mostly javascript. We want to store the javascript in in blob storage / CDN. But until we release it we only want our office to have access. I understand that I can't create a firewall rule for Azure blob, so restricting access to our office IP is out.

From what I have read Shared Access Signatures might be the way to go. Can someone confirm that this is a valid direction to go? Also, can someone point out what mechanism I should be looking at to restrict access to these containers. i.e. a way to restrict the tokens to only our devs.

I know this may come across as weak, but I really have no clue how MS does things coming from a purely *nix world. All the tutorials have are a few lines of code saying how to access stuff using SAS but not much on setting up the policies in the first place. Also, will this approach work with CDN?

score 4 · Accepted Answer · answered Jun 03 '13 at 17:59

4

Shared Access Signatures are implemented as querystrings containing valid from/to times on the link, along with a hash.

You can create a SAS on any blob via any language. Here's a Java tutorial, for example. At this point, you can embed the resultant link into your web page. Should work just like a regular url.

SAS isn't going to work against CDN, as CDN is only for public blobs.

answered Jun 03 '13 at 17:59

David Makogon

69,407
21
141
189

That tutorial really helped, thanks. Now I suppose I also have to create a service for the app requiring the asset stored on 'blob storage' to be able to retrieve an SAS token. Since that doesn't have to be on storage I can limit access to this using a firewall or use of credentials. How is this part usually done? Also, do you know if there is a way to make an SAS token that has no expiry? Thanks for the help so far. – Bill Rosmus Jun 03 '13 at 23:45
If your app is the `source` retrieving the blob, it doesn't need any SAS - it simply connects with storage name + key. In fact, every single language SDK wrapping the storage REST API takes a connection string made up of namespace+key (and this key is private to you - never give it away; you can always re-gen it, but just... don't give it away). And for non-expiring SAS, just make the 'to' date something like 1/1/2030 and hope you don't have a Y2.3K bug. :) – David Makogon Jun 03 '13 at 23:59
The only time you need a SAS is when you're providing a blob URI to someone, and that blob is *private*. This works great if, say, you store monthly statement PDFs in blob storage. A user is viewing their page, wants to see their monthly statement. You can either download blob to your VM and stream it to the user's browser, OR... just generate an SAS for the pdf valid for, say, 10 minutes, insert the URI in an `` tag, and let the user click to retrieve (and not use up your VM's bandwidth, instead going straight to the storage service). – David Makogon Jun 04 '13 at 00:01
Yeah far future date makes sense. My app isn't the source retrieving the blob, that will be done by a number of pages for a web based app. They'll need to access the assets securely until the project goes live and they can drop the tokens. I'll figure something out. Thanks again. – Bill Rosmus Jun 04 '13 at 00:09

score 4 · Answer 2 · edited Jul 07 '15 at 18:53

My understanding from the “Overview of the Windows CDN” page on MSDN is that only blobs that are publically available can be cached with the Windows Azure CDN. To make a blob publically available for anonymous access, you must denote its container as public. Once you do so, all blobs within that container will be available for anonymous read access.

If the public access to the container is set to enable read access then any anonymous using having the url to the blob container can read all blobs in that container. READ access does not automatically give WRITE, DELETE, or LIST access to the container.

If the blob container is public, then also creating a shared access signature or stored access policy won’t prevent that public access. If you want to control access to the container using shared access signature or stored access policy then you must set public access to OFF. This is discussed in “Controlling Access to Windows Azure Blob Containers with Java” and elsewhere on MSDN.

Azure Shared Access Signatures To Restrict Access

2 Answers2