Admins may be asked to allow delegated access to resources in Azure storage accounts. Shared access tokens (SAS) are a way to provide delegated access. In this AZ-104 guide, we will look at shared access tokens and how they can be configured for storage account access in Azure.
What are Shared Access Signatures?
Shared Access Signatures (SAS) in Azure are a security feature that provides controlled access to resources in your Azure storage account. They are a great solution where you need to grant limited access, and secure access is required without exposing your storage account keys.
You can provide SAS to clients or others that are not trusted with the storage account key but to whom you want to delegate access to storage resources. These shared access signature tokens grant access for a specified period. They can also configure access permissions for different storage account resources.
Note the following key points regarding SAS:
- Secure Delegated Access: SAS tokens grant secure, temporary access to storage resources
- Customizable Permissions: They allow for specifying permissions, such as read or write access, and setting a validity period
- Types of SAS: Includes Service SAS, which is specific to a resource, and Account SAS, which provides access to multiple resources in a storage account
- User Delegation SAS: A specific type secured with Microsoft Entra credentials, offering enhanced security
- Creation and Management: SAS tokens can be created and managed via the Azure portal or Azure Storage Explorer, with the ability to define permissions, start and expiry times, and IP address restrictions
How do Shared Access Signatures work?
A shared access signature (SAS) is a token attached to the URI of an Azure Storage resource. This token includes a unique set of query parameters specifying the access permissions for the client. Among these is a signature, formed from the SAS parameters and signed with the key used in creating the SAS. Azure Storage uses this signature to validate and authorize access to the storage resource.
Here’s an overview of SAS tokens workflow:
- Your application sends the SAS token to Azure Storage within a REST API request
- The storage service checks the SAS for validity. If it’s valid, the request is authorized
- If the SAS token is invalid, the request is denied. It will result in a 403 (Forbidden) error code returned
What does it look like? In the example below, you will note the following components: storage resource URI, delimiter, and SAS token.
Types of Shared Access Signatures
Azure Storage supports three types of shared access signatures (SAS):
- Account SAS: This SAS type allows delegation of access to resources in one or more storage services. It encompasses all operations available via a service SAS, including access to service-level operations like Get/Set Service Properties and Get Service Stats. It also enables delegation of read, write, and delete operations on blob containers, tables, queues, and file shares, which are not allowed with a service SAS
- Service SAS: This SAS type delegates access to a resource in a single storage service, such as Azure Blob Storage, Azure Queue Storage, Azure Table Storage, or Azure Files. Further information on creating and using a service SAS can be found in the provided documentation and examples
- User Delegation SAS: Introduced in version 2018-11-09, this SAS is secured with Azure Active Directory credentials and is supported only for Blob Storage. It allows granting access to containers and blobs. More information is available on how to create a user delegation SAS
Creating SAS Tokens for storage access
Let’s look at the process of generating SAS tokens. Log in to the Azure Portal and navigate to your storage account. Under the Security + networking menu, click Shared access signature.
You will see the Shared access signature settings. You will note that until you check the Allowed resource types for the SAS, the Generate SAS and connection string is greyed out. Take note of the different types of Shared Access Signatures detailed in the preceding section.
Also note the start date and time and how you can restrict the IP addresses able to connect using the SAS token.
Once you select the Allowed resource types, the button to Generate SAS and connection string is available. Click the button to generate SAS tokens.
Once you click the button, you will see the following generated:
- Connection string
- SAS token
- Blob service SAS URL
- File service SAS URL
- Queue service SAS URL
- Table service SAS URL
Using the SAS token and URL values
Once the Blog SAS token and URLs are displayed, be sure you copy these to a safe place like a password manager, as they will only be displayed once. You can’t retrieve them afterward.
To use the information, you append the SAS token (URI) to the URL for a storage service. With this, you can enable fine-grained access control to Azure storage services.
Important considerations with Shared Access Signature tokens
There are a few important considerations to make when using and leveraging SAS tokens. Note the following:
- If a SAS URI and token are exposed, it can be used by anyone who has it
- It is good to consider locking the SAS token down to a set IP or IP range to restrict its use further
- If you are using a SAS token with an application, if the token expires and the renewal fails, the application will no longer be able to access the storage resources
Frequently asked questions
How do Account SAS and Service SAS differ in Azure Storage?
Account SAS and Service SAS serve distinct purposes in Azure Storage. While Account SAS provides broad access across multiple storage services, enabling a range of operations including service-level tasks and container manipulations, Service SAS is more specific, granting access to resources within a single service like Azure Blob Storage or Azure Files.
What advancements does User Delegation SAS bring to Azure Blob Storage?
User Delegation SAS, a newer addition, enhances security in Azure Blob Storage by integrating with Azure Active Directory. This specialized SAS type focuses on Blob Storage, allowing for fine-grained access control over containers and blobs using Azure AD credentials.
Can you explain the process Azure Storage uses to validate a SAS token?
When a SAS token is submitted as part of a REST API request, Azure Storage authenticates it by verifying the signature. This signature, created from SAS parameters and the original key used for SAS generation, is crucial for Azure Storage to determine the legitimacy of access requests.
What happens if a SAS token is incorrect or expired in Azure Storage?
If a SAS token is invalid, due to incorrect parameters or expiration, Azure Storage rejects the access request. This presents as a 403 (Forbidden) error, indicating that the request could not be processed due to invalid SAS credentials.
How does the signature parameter in a SAS token enhance security in Azure Storage?
The signature parameter in a SAS token acts as a security measure in Azure Storage. It is generated based on the SAS parameters and the key used for creation. This signature is essential for Azure Storage to authorize access, ensuring that the request aligns with the permissions defined in the SAS token.
Wrapping up Shared Access Signature SAS tokens
Shared access signature tokens are an important part of granting access to Azure storage container resources. Combined with other security mechanisms, they can help provide granular access to Azure storage resources without sharing account access keys to the Azure storage service.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
