Azure Storage – Part 4 – BLOB Shared Access Signature

Santosh Gaikwad

Santosh Gaikwad

Connect on LinkedIn      Follow SCI Page

Write to admin@sharecareinspire.com
Santosh Gaikwad

Latest posts by Santosh Gaikwad (see all)

<< Part 1      <<Part 2      <<Part 3      >>Part 5

What is BLOB?

Azure Blob is a storage  service for storing large amounts of unstructured object data, such as text or binary data, that can be accessed from anywhere in the world via HTTP or HTTPS. You can use Blob storage to expose data publicly to the world, or to store application data privately.

To know more about Blobs please refer articles Part 1, Part 2, Part 3

Why Secure Access?

In previous part we have seen that you can use keys and connection string to access and modify data in blobs. But those keys and connection string are very sensitive and if compromised, can be misused by any one which may lead to destruction of you data in Azure Blobs.

OK, so it is understood that those keys need to be protected, but what if you have your partners who want to access some data and store some data in your Azure Blobs.

Very simple, share the keys with them right? Ah wait No ….

Microsoft Azure has given you more secure ways to deal with such scenarios which is called Shared Access Signature, this allows the client to access the containers and blobs in your storage account without knowing your storage account keys.

Secure access to blob storage means a secure connection for data transfer, and access to the Blobs would be given through authentication and authorization.

Blobs support both HTTP and secure HTTPS requests. It is recommended to use HTTPS connections for data transfer.

What are default permissions on Blobs?

At the time of creation of Blob container, you can set the permissions for each container in blob storage to one of three values:

Private – no public access to blobs or containers, you can only access the blobs and containers if you have the storage account name and key, or you use a shared access signature.

Blob – public read access for blobs, anybody with the URL to a blob in the container can read the blob and the blob properties and metadata.  shared access signature is required with appropriate permissions to read or write content to blob.

Container – Public read access for blob containers and blobs, you can read properties of container, blob and also can read the content of content and blob. However can’t modify, upload, or delete blobs.

Storage Access Types
Storage Access Types

How to provide secure access to Blobs?

Using Shared Access Signature you can Grant restricted access rights to containers and blobs. You can provide a shared access signature to users you don’t trust with your storage account key or your clients. You can give them a shared access signature that will grant them specific permissions to the resource for a specified amount of time.

How a shared access signature works?

A shared access signature is a signed URI that points to one or more storage resources and includes a token that contains a special set of query parameters. The token indicates how the resources may be accessed by the client. One of the query parameters, the signature, is constructed from the SAS parameters and signed with the account key. This signature is used by Azure Storage to authenticate.

The SAS token is a string you generate on the client side. A SAS token you generate with the storage client library. You can create an unlimited number of SAS tokens on the client side.

When a client provides a SAS URI to Azure Storage as part of a request, the service checks the SAS parameters and signature to verify that it is valid for authenticating the request. If the service verifies that the signature is valid, then the request is authenticated. Otherwise, the request is declined with error code 403 (Forbidden).

How to Create Share Access Signature?

You as owner of the storage account need to generate a shared access signature using account key and provide it to the clients for consumption.

Will see example in upcoming articles.

How does SAS URI looks like?

Let’s consider I have a blob entry with text file which has all my contacts

https://sharedkeys.blob.core.windows.net/mynewcontainer/MyContacts.txt

Blob URI
Blob URI

If this resource has to be accessed by the client’s applications, they need to access this resource with URI which looks something like blow RUI.

https://sharedkeys.blob.core.windows.net/mynewcontainer/MyContacts.txt?sv=2015-04-05&st=2015-04-29T22%3A18%3A26Z&se=2015-04-30T02%3A23%3A26Z&sr=b&sp=rw&sip=168.1.5.60-168.1.5.70&spr=https&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

Does it look wacky?  Hmmm, let’s have a close look at it, and see what all things it contains.

  • Blob URI: This is the address of the blob as stated above.
    https://sharedkeys.blob.core.windows.net/mynewcontainer/MyContacts.txt 
  • Storage services version (sv): This tells which version of the storage services to use, in above example: sv=2015-04-05, this is optional, and will be set to the newest version available if not specified.
  • Start Time (st): This is the time the SAS becomes valid. If omitted, the SAS is effective immediately. This must be in ISO 8061 format. In above example: st=2015-04-29T22%3A18%3A26Z
  • Expiration Time (se): This is the time after which the SAS is no longer valid. In above example: se=2015-04-30T02%3A23%3A26Z
  • Storage Resource (sr): This tells if the resource is a blob, queue, etc. in above example: sr=b, which says the resource is a blob, (sr=c for container).
  • Permissions (sp): This defines what operations can be performed against the storage resource. In above example: sp=rw, which grants Read (r) and Write (w) access.
  • Shared IP range: The range of IP addresses from which a request will be accepted in above example, sip=168.1.5.60-168.1.5.70
  • Shared Protocol: Protocol on which data will be exchanged, only requests using HTTPS are permissible.  In above example, spr=https
  • Signature (sig): This is used to authenticate the blob. Signature uses the SHA256 algorithm, then encoded using Base64 encoding. (That sounds hard, doesn’t it? Fortunately, the storage client library has a call to create this for you, unless you just like to do things the hard way.) in above example: sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

 

<< Part 1      <<Part 2      <<Part 3      >>Part 5


Check Articles From Categories      Health and Parenting      Inspiring Stories      Technology      Microsoft Azure      SharePoint O365

Leave a Reply

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