Unger Technologies LLC

GREG UNGER MY FACEBOOK ATHLETE PAGE MY YOUTUBE CHANNEL Follow me on Twitter FOLLOW ME ON TWITTER

Do you know what Shared Access Signatures are?

Overview

Using a shared access signature (SAS) is a powerful way to grant limited access to objects in your storage account to other clients, without having to expose your account key. In Part 1 of this tutorial on shared access signatures, we'll provide an overview of the SAS model and review SAS best practices. Part 2 of the tutorial walks you through the process of creating shared access signatures with the Blob service.

What is a shared access signature?

A shared access signature provides delegated access to resources in your storage account. This means that you can grant a client limited permissions to objects in your storage account for a specified period of time and with a specified set of permissions, without having to share your account access keys. The SAS is a URI that encompasses in its query parameters all of the information necessary for authenticated access to a storage resource. To access storage resources with the SAS, the client only needs to pass in the SAS to the appropriate constructor or method.

When should you use a shared access signature?

You can use a SAS when you want to provide access to resources in your storage account to a client that can't be trusted with the account key. Your storage account keys include both a primary and secondary key, both of which grant administrative access to your account and all of the resources in it. Exposing either of your account keys opens your account to the possibility of malicious or negligent use. Shared access signatures provide a safe alternative that allows other clients to read, write, and delete data in your storage account according to the permissions you've granted, and without need for the account key.
A common scenario where a SAS is useful is a service where users read and write their own data to your storage account. In a scenario where a storage account stores user data, there are two typical design patterns:
1. Clients upload and download data via a front-end proxy service, which performs authentication. This front-end proxy service has the advantage of allowing validation of business rules, but for large amounts of data or high-volume transactions, creating a service that can scale to match demand may be expensive or difficult.
sas-storage-fe-proxy-service
2. A lightweight service authenticates the client as needed and then generates a SAS. Once the client receives the SAS, they can access storage account resources directly with the permissions defined by the SAS and for the interval allowed by the SAS. The SAS mitigates the need for routing all data through the front-end proxy service.
sas-storage-provider-service
Many real-world services may use a hybrid of these two approaches, depending on the scenario involved, with some data processed and validated via the front-end proxy while other data is saved and/or read directly using SAS.
Additionally, you will need to use a SAS to authenticate the source object in a copy operation in certain scenarios:
  • When you copy a blob to another blob that resides in a different storage account, you must use a SAS to authenticate the source blob. With version 2015-04-05, you can optionally use a SAS to authenticate the destination blob as well.
  • When you copy a file to another file that resides in a different storage account, you must use a SAS to authenticate the source file. With version 2015-04-05, you can optionally use a SAS to authenticate the destination file as well.
  • When you copy a blob to a file, or a file to a blob, you must use a SAS to authenticate the source object, even if the source and destination objects reside within the same storage account.

Types of shared access signatures

Version 2015-04-05 of Azure Storage introduces a new type of shared access signature, the account SAS. You can now create either of two types of shared access signatures:
  • Account SAS. The account SAS delegates access to resources in one or more of the storage services. All of the operations available via a service SAS are also available via an account SAS. Additionally, with the account SAS, you can delegate access to operations that apply to a given service, such as Get/Set Service Properties and Get Service Stats. You can also delegate access to read, write, and delete operations on blob containers, tables, queues, and file shares that are not permitted with a service SAS. See Constructing an Account SAS for in-depth information about about constructing the account SAS token.
  • Service SAS. The service SAS delegates access to a resource in just one of the storage services: the Blob, Queue, Table, or File service. See Constructing a Service SAS and Service SAS Examples for in-depth information about constructing the service SAS token.

How a shared access signature works

A shared access signature is a 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.
The account SAS and service SAS tokens include some common parameters, and also take a few parameters that that are different.

Parameters common to account SAS and service SAS tokens

  • Api version An optional parameter that specifies the storage service version to use to execute the request.
  • Service version A required parameter that specifies the storage service version to use to authenticate the request.
  • Start time. This is the time at which the SAS becomes valid. The start time for a shared access signature is optional; if omitted, the SAS is effective immediately.
  • Expiry time. This is the time after which the SAS is no longer valid. Best practices recommend that you either specify an expiry time for a SAS, or associate it with a stored access policy (see more below).
  • Permissions. The permissions specified on the SAS indicate what operations the client can perform against the storage resource using the SAS. Available permissions differ for an account SAS and a service SAS.
  • IP. An optional parameter that specifies an IP address or a range of IP addresses outside of Azure (see the section Routing session configuration state for Express Route) from which to accept requests.
  • Protocol. An optional parameter that specifies the protocol permitted for a request. Possible values are both HTTPS and HTTP (https,http), which is the default value, or HTTPS only (https). Note that HTTP only is not a permitted value.
  • Signature. The signature is constructed from the other parameters specified as part token and then encrypted. It's used to authenticate the SAS.

Parameters for an account SAS token

  • Service or services. An account SAS can delegate access to one or more of the storage services. For example, you can create an account SAS that delegates access to the Blob and File service. Or you can create a SAS that delegates access to all four services (Blob, Queue, Table, and File).
  • Storage resource types. An account SAS applies to one or more classes of storage resources, rather than a specific resource. You can create an account SAS to delegate access to:
    • Service-level APIs, which are called against the storage account resource. Examples includeGet/Set Service PropertiesGet Service Stats, and List Containers/Queues/Tables/Shares.
    • Container-level APIs, which are called against the container objects for each service: blob containers, queues, tables, and file shares. Examples include Create/Delete Container,Create/Delete QueueCreate/Delete TableCreate/Delete Share, and List Blobs/Files and Directories.
    • Object-level APIs, which are called against blobs, queue messages, table entities, and files. For example, Put BlobQuery EntityGet Messages, and Create File.

Parameters for a service SAS token

  • Storage resource. Storage resources for which you can delegate access with a service SAS include:
    • Containers and blobs
    • File shares and files
    • Queues
    • Tables and ranges of table entities.

More information