Shared Access Signatures in Azure

In the early days of Azure Storage, managing access to resources was a complex endeavor. The traditional access control approach using firewall-based IP restrictions or leveraging Azure's Access Control Service was limiting and cumbersome for advanced scenarios like granting time-limited permissions to certain resources. To overcome these challenges, Microsoft introduced Shared Access Signatures (SAS) in Azure's Cloud Storage services.

What is a SAS token and Why do we need it?

A Shared Access Signature (SAS) is a unique string of characters generated by Azure that you can use to grant access to your storage resources without exposing your primary or secondary account keys. Essentially, SAS tokens allow fine-grained, URL-based control over individual Azure Storage objects.

SAS tokens can be controlled.

  1. What resources the client may access?
  2. What permissions do they have to those resources?
  3. How long the SAS token is valid?

For example, you might give a client a SAS token that allows read-only access to a specific Blob Storage container for the next 2 hours. This allows very specific, secure, and temporary access to Azure resources.

Drawbacks of SAS tokens

While SAS tokens offer tremendous advantages, they come with a few drawbacks.

  1. Revoking SAS tokens: Once issued, an SAS token can't be revoked without invalidating the account's access keys or removing the stored access policy that was used to create the SAS token. This can impact other applications or services using the same keys or policies.
  2. Security Risks: If a SAS token is leaked, it can be used by anyone to access your data until the token expires.
  3. Complexity: Generating and managing SAS tokens, especially for larger applications, can add to the complexity of your setups.

Improvements and Best practices

To mitigate the drawbacks of SAS tokens and make them more secure, Azure has come up with improvements like Azure AD-based authorization, and user delegation SAS tokens in Azure Blob Storage.

For handling SAS tokens securely

  1. Always use HTTPS for transferring data and tokens.
  2. Be specific with the resource, permission, and expiry time.
  3. Use stored access policies to manage groups of SAS tokens.
  4. Avoid distributing SAS tokens that allow full permissions to resources.

A Sample SAS token

Here's a simple way to generate a SAS token for a blob object with C#

// Get a reference to a blob within the container.
BlobClient blob = container.GetBlobClient(blobName);
// Build a shared access signature which expires in 1 hour
BlobSasBuilder sasBuilder = new BlobSasBuilder()
{
    BlobContainerName = containerName,
    BlobName = blobName,
    Resource = "b",
    ExpiresOn = DateTimeOffset.UtcNow.AddHours(1)
};
// Specify read permissions for the SAS
sasBuilder.SetPermissions(BlobSasPermissions.Read);
// Use key to get the SAS Token
BlobSasQueryParameters sasToken = sasBuilder.ToSasQueryParameters(
    new StorageSharedKeyCredential(accountName, accountKey)
);
// Store SAS Token for later use
string sasUrl = blob.Uri + sasToken.ToString();

Conclusion

while Azure SAS tokens come with certain considerations, their utility in terms of granting secure, fine-grained access to Azure Storage resources is undeniable. As with any powerful tool, appropriate caution and understanding are required to use them effectively.


Similar Articles