Microsoft Azure: Understanding Shared Access Signatures (SAS)


In today’s Ask the Admin, I’ll explain how Shared Access Signatures (SAS) can be used to grant access to objects in storage without revealing the storage account key.

Azure storage accounts come in two flavors: standard accounts, which provide access to Azure Storage services such as tables, queues, files, blobs, and disks; and blob storage accounts, which are optimized for blob storage. But whichever account type you choose, a master key is used to grant administrative access. For more information on Azure Storage, see Deploying a Microsoft Azure Storage Account on the Petri IT Knowledgebase.

But if you want to grant limited or temporary access, giving away your storage account key isn’t the best idea. To solve this problem, Azure uses Shared Access Signatures (SAS) for safely delegating access to objects in storage. A Shared Access Signature is a Uniform Resource Identifier (URI) that includes all the information about the resources to which you want to grant access, and relevant permissions in the form of a token.

SAS Use Cases

Shared Access Signatures can be used in any situation where you don’t want to give away your storage account key, primary or secondary, because both provide full administrative access to storage. Just as in any other situation where you would grant access to sensitive systems or data, it’s best to implement the principle of least privilege, where the client or system only gets the access needed to complete the required tasks, nothing more.

Web applications can use SAS to allow users to upload or download data to Azure Storage without using a front-end proxy service that might otherwise be used for authentication or to apply business rules. Or a hybrid approach can be deployed where some operations are processed via a front-end proxy and others communicate directly with Azure Storage.

Shared Access Signatures in use in Microsoft Azure (Image Credit: Microsoft)
Shared Access Signatures in use in Microsoft Azure (Image Credit: Microsoft)

Copying files or blobs between storage accounts requires SAS to authenticate with the source blob. Additionally, Azure Resource Manager (ARM) uses SAS to access linked templates, which must be stored in Azure Storage. For more information on working with linked ARM templates, see Microsoft Azure: Using Linked ARM Templates on Petri.

Service vs. Account SAS

A service SAS provides access to a resource in one storage service: i.e., a blob, queue, table, or file service. An account SAS provides access to one or more storage services, but additionally you can delegate access to tasks, read, write, and delete operations.

Token Parameters

SAS tokens contain a set of query parameters that indicate how the client can access the storage resources, including a signature that is generated from the SAS parameters and signed using the storage account key. It’s this signature that’s used to authenticate the client to Azure Storage. Parameters in the token include, start time, expiry time, permissions, IP, protocol, signature, and many more.

Stored Access Policy

Except for account SAS, which must be ad hoc, SAS can be ad hoc or implemented using a stored access policy. Ad hoc SAS have their start time, expiry time, and permissions specified on the SAS URI. But stored access policies are defined on storage resources and can be used to create multiple SAS. When you associate an SAS with a stored access policy it inherits the constraints defined in the policy.

Anyone who can access an SAS URI can use it, so if it’s published on the Internet, the resources it provides access to are wide open. And it’s important to note that ad hoc SAS can only be revoked by changing the storage account key. Access can also be revoked by deleting the storage access policy referred to by the SAS, or wait for the specified expiry time to be reached.