In this video, create a shared access signature (SAS) to control access to an Azure Storage blob.
- [Instructor] Now we want to look at access control. And we will use shared access signatures on blobs just like we can in the rest of the storage account. But just before we do, come back to the azure portal, and take a look at the storage account. Remember the access keys were essentially the root passwords to our storage account overall. So by default, nobody has access to the storage account unless you have access to one of these two keys. Then in addition, we have shared access signatures where we generate a token that is potentially temporary but certainly limited access into the storage account.
Now in our storage account, remember this is learn azure blobs today. It's not a general purpose storage account. So the only service available is blobs and we have the find permissions as we like. But there is one other consideration; so go back to overview and since its not general purpose, I didn't have to click on blobs. All I'm seeing is the blob containers. Let me show you what happens when I add a container here. We have the name of the container, and access level.
The default is private so you need either an access key or a SAS token to be able to access the service. But if you are hosting images or content for services that are in fact public facing, it might be appropriate to have a container that allows anonymous read access to blobs. So for example, if I'm publishing photos online, I can place my photos in storage account in a container and make that container access level blob. Meaning if I give you the URL to the blob itself you'd be able to download that blob.
So this means we can use storage accounts as the native storage on the public internet for content that needs to be public. And so we don't have to build our webs over we don't have to build a service to serve that content. Now bear in mind you do pay for access to these blobs so consider this storage tear and consider placing a service in front of it. So whether its a CDN, a content distribution network or something like it, it's often necessary to be able to control the content type to determine some metrics like click slims and things like that.
But after all ind ious, you can actually serve content directly from a storage account by making a container blob- access level. If you want to allow clients to also traverse the structure, and actually look at what else is available in the container you could give them less permissions as well so that's store read only access but it is read and discover. Now, if you are using private we can still use shared access signatures to learn limited access to blobs in this container. Let's go to visual studio Okay, I will simply copy the lock blobs in fact I'll copy the ten blobs.......
File again try again drop hold down control new file..... if to rename..... (Keyboard typing) we just make really simple quick example again Rename the class, for shared access signatures as we expect we generate the client enter before.... the contents here or the method (keyboard typing) and deleting the contents of the method also rename the method and this is for obtaining a shared access signature token.
Now remember you can publish a container on the public internet and let people hit URLs directly. What I'm going to do though is a little bit different. I'm going to assume that there is a specific client that needs specific access on a specific blob and so right here where I have the client, we going to trade container reference or container by asking the client (keyboard typing) and I know we have a photos folder for this container I'm going to ask for blob reference so br container reference get me a blob reference and now we have Madagascar from before and now, I'm going to ask for a SAS token for read access to that specific blob.
SAS token is just a string copy, string, So global valuable here and so when we set up our class and the class initialize SAS token read or come from the blob, there's a blob reference get shared access signature. And a shared access signature is generated by providing a new shared access blob policy.
We set the properties in there. So the shared access blob policy has permissions and in this case, shared access blob permissions read will be sufficient. But SAS tokens all secrets so do make sure you limit the time. So make sure it expires and for that we have a new date time off set second overload generated from date time dot now add a few minutes two minutes and that ought be enough for the lifetime of this token.
SAS token here will be static string versus token read created during class initialization available as long as these tests within this class is running and so down here, a test for zero SAS I should be able to use SAS token to gain access to the blob. Now bear in mind we've asked for read access on that specific one and only blob so what I can do is navigate all the way down to it and read the blob. I cannot query I cannot check if other things exist around it et cetera.
so the blob itself a new cloud blob and that new cloud blob will have URL I will copy and paste that from the pol clay in a moment and we renew storage credential but the only thing I have for credential is SAS token. So the code that you see down here in this test method.... This code does not have access to the key the route password for the storage account.
What it has is the SAS token and it is going to connect to that blob directly. So we come to our photos in the portal unto Madagascar looking at its properties click to copy the URL, paste, and so there we have a blob with sufficient permissions to read from it. So ill await, blob download.... I'll just put it in the memory stream temporarily (keyboard typing) control dot using system IO and also the memory stream.
The point is just to prove that we can download from that blob having this limited permission. Save all Old And we run the test. And so, Like for the other services, you're aware that we can create SAS tokens and for globs there is the exception now yes you can create SAS tokens and you absolutely should practice many more privilege but when you have public content you can serve that content directly from the blob's service.
Remember here, when we create a container add container remember this public access level option can save you lot of time and hustle of course private nobody has access unless you give them SAS token or the access keys and blob ideal for serving content directly are of storage accounts to consider combining it with the content distribution network and probably custom domain as well, but it's a way to basically eliminate having to build a service entirely and just serve the content directly.
- Creating a Blob storage account
- Stored access policies for granting privileges
- Shared access signatures
- Encrypting data at rest
- Connecting to blob containers
- Working with append and block blobs
- Azure Storage metadata
- Blob performance considerations