✎ Co-author — Damle Amit
In today’s world, sharing of data amongst customers, business stakeholders & partners has become a key business requirement. Organizations are using multiple ways to share data like sharing through email, FTP, Custom API’s, Azure Blob & Azure Data Share. This choice depends on various factors like data volume, cost, security, governance etc.
Typically I come across scenarios wherein Customers wants easiest method to share the data with their partner echo system using Azure blob with restricted access for a limited period of time.
Although it seems to be relatively simple problem statement, it can be confusing for some. In this article, I am going to discuss methods to solve above problem statement with highly secured & most recommended way of creating a SAS token using user delegation SAS.
❐ What is Shared Access Signatures (SAS)?
Probably if you are new and unfamiliar with SAS tokens at all, A Shared Access Signatures (SAS) provides a secured delegated access to resources in your storage account with an ability to have granular control over what resources a client can access , permissions (read, write, delete, add, create, list etc.) to those resources & most importantly the access validity.
❐ What is SAS token ?
The SAS token is a string that is generated by using either Azure Storage client libraries, Azure CLI, REST API or Powershell. After you create a SAS token, you can distribute it to client applications that require access to resources in your storage account.
You can sign a SAS token with a user delegation key or with a storage account key (Shared Key).
Here’s an example of a service SAS URI, showing the resource URI and the SAS token.
❐ Azure storage supports 3 types of shared access signatures
- Account SAS
- Service SAS
- User delegation SAS
❐ Key differences for Types of Shared Access Signatures -
It is always recommended to use a User Delegation SAS when possible. A user delegation SAS provides superior security compared to a service or an account SAS.
❐ User Delegation SAS creation flow
Following schematic describes User delegation creation schematic flow -
➊ External User(in our case Partner Team user) who wants to have access to the Azure Storage requests for a restricted access.
Use RBAC to grant the desired permissions to the security principal who will request the user delegation key. An Azure AD security principal may be a user, a group, a service principal, or a managed identity.
The authorized security principal should have one of the below roles at the storage account, resource group, or the subscription level to get OAuth Access token from Azure AD & generate User Delegation Key -
▬ Storage Account Contributor
▬ Storage Blob Data Contributor
▬ Storage Blob Data Owner
▬ Storage Blob Data Reader
▬ Storage Blob Delegator
All above built-in RBAC roles include Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action to generate User Delegation Key.
➋ Acquire an OAuth 2.0 token from Azure AD.
➌ Use the token to request the user delegation key by calling the Get User Delegation Key operation.
➍ Use the user delegation key to construct the SAS token with the appropriate fields specifying the Storage account name, container name, expiry date & permissions.
➎ Create a SAS URL & provide it to the requesting External User(in our case Partner Team user) for their consumption.
How to create a User Delegation SAS using Azure CLI ?
Below 2 steps are used to create a User Delegation SAS using Azure CLI
1. Assign permission with Azure RBAC —
The following example assigns the Storage Blob Data Contributor role, which includes the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action. The role is scoped at the level of the storage account.
Replace placeholder values in angle brackets with your own values -
az role assignment create \
--role "Storage Blob Data Contributor" \
--assignee <email> \
For more information about the built-in roles that include the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action, see Azure built-in roles.
Now the assignee is ready to generate an User Delegated SAS Token.
2. Create a user delegation SAS for a container -
The following example returns a user delegation SAS token for a container. Remember to replace the placeholder values in brackets with your own values:
az storage container generate-sas \
--account-name <storage-account> \
--name <container> \
--permissions acdlrw \
--expiry <date-time> \
--auth-mode login \
When creating a user delegation SAS, the
--as-user parametersare required.
Specify login for the
--auth-modeparameter so that requests made to Azure Storage are authorized with your Azure AD credentials.
--as-userparameter to indicate that the SAS returned should be a user delegation SAS.
Note — When you create a user delegation SAS with the Azure CLI, the user delegation key that is used to sign the SAS is created for you implicitly.
Supported permissions for a user delegation SAS on a container include Add, Create, Delete, List, Read, and Write. Permissions can be specified singly or combined. For more information about these permissions, see Create a user delegation SAS.
What are the best practices while using SAS?
✓ Managing SAS can sometimes becomes a nightmare. One of the best solution is to create an application/middleware that can authenticate external users and allow them to request SAS for a specific operation on a specific container or file & provide SAS for consumption.
✓ Always use HTTPS to create or distribute a SAS. If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack is able to read the SAS.
✓ If you set the start time for a SAS to the current time, failures might occur intermittently for the first few minutes due to clock skew. In general, it is suggested to set the start time to be at least 15 minutes in the past.
✓ Make sure you are prepared if a SAS is compromised. Have a revocation plan in place for a SAS.
How to revoke a user delegation SAS?
If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your storage account.
Some times there may be scenarios to invalidate User Delegation SAS e.g. SAS is leaked/compromised.
revoke-delegation-keys command revokes all of the user delegation keys associated with the specified storage account. Any shared access signatures associated with those keys are invalidated.
Remember to replace placeholder values in angle brackets with your own values:
az storage account revoke-delegation-keys \
--name <storage-account> \
Note — User delegation SAS is based on creating a SAS token on the scoped permissions of an AAD user instead of storage access keys. Once the SAS token is created, it is the responsibility of the organizations to share it cautiously with intended users only since it can be used by anyone who obtains it.
I hope this blog helped you in understanding the basics of User Delegation SAS along with recommended best practices. Happy Learning!!!
Please Note — All opinions expressed here are my personal views and not of my employer.