how to revoke Shared Access Signature in Azure SDK

Question

I could not find any code sample for revoking the created Shared Access Signature access on blob, can anyone provide me link or reference for removing the Shared Access Signature access created earlier.

Tendinous

When you created Shared Access Signature, did you make use of container access policy? – Coseismal

See also: stackoverflow.com/questions/21210743 stackoverflow.com/questions/46344983 – Paulus

Answer 1

Even if shared access signature (SAS) is based on a stored access policy (SAP), you can only revoke SAP, not individual SAS.

Azure Storage security guide has good details: https://learn.microsoft.com/en-us/rest/api/storageservices/create-service-sas#revoke-a-sas

SAS not based on SAP - can't be revoked:

If you are using ad hoc URIs, you have three options. You can issue SAS tokens with short expiration policies and wait for the SAS to expire. You can rename or delete the resource (assuming the token was scoped to a single object). You can change the storage account keys. This last option can have a significant impact, depending on how many services are using that storage account, and probably isn't something you want to do without some planning.

SAS based on SAP - can be revoked by revoking SAP:

If you are using a SAS derived from a Stored Access Policy, you can remove access by revoking the Stored Access Policy – you can just change it so it has already expired, or you can remove it altogether. This takes effect immediately, and invalidates every SAS created using that Stored Access Policy. Updating or removing the Stored Access Policy may impact people accessing that specific container, file share, table, or queue via SAS, but if the clients are written so they request a new SAS when the old one becomes invalid, this will work fine.

Best practice:

Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.

Inlaw

Answer 2

Context

• MSFT Azure storage account (live version as of 2019-11-26)
• MSFT Azure storage permissions as managed by Shared Access Signature (SAS)

Problem

• User user145610 wants to immediately revoke a deployed SAS
  • (e.g., because SAS allows authentication into Blob Storage, and the SAS has been compromised, requiring immediate remediation to prevent unauthorized data breach)

Workarounds already mentioned

• Other answers already appear in this thread discussing the use of Shared Access Policy (aka Stored Access Policy) (SAP)
• SAS generated based on SAP has limitations, only five SAPs can be attached to a a blob container within a storage account.

Workaround: Regenerating Account Keys

• One workaround that does not appear in this thread (at the time of this posting) is the ability to regenerate the account key used to originally create the SAS, as documented in one of the links in the see also section of this answer.

Regenerating an account key will cause all application components using that key to fail to authorize until they're updated to use either the other valid account key or the newly regenerated account key. Regenerating the account key is the only way to immediately revoke an ad hoc SAS.

• Consequently, one potential workaround is to generate and deploy SASs based on the secondary account key, and have the expectation that you will routinely regenerate the secondary account key whenever immediate revocation of one or more SASs becomes necessary.
  • (Obviously, this is not a desirable circumstance where many SAS tokens are deployed and dependent on the secondary account key, because they will all be rendered invalid upon regeneration of the key)

Solution

• The inability to deploy a large number of SAPs, combined with the potentially unfavorable side-effects of having to regenerate account keys suggests that a potential solution is to re-engineer the architecture of your project to use ActiveDirectory for controlling authorization and access control, and the generation of SAS tokens.
• SASs based on SAPs may be better suited for cases where there are only few clients requiring access, and the probability of the SASs getting compromised is extremely low.
• As of this writing, MSFT Azure storage supports the generation and use of SAS tokens based on ActiveDirectory accounts.

See also

• How many access policies can I create and add on the same one Azure container?
• https://learn.microsoft.com/en-us/azure/storage/common/storage-auth
• https://learn.microsoft.com/en-us/rest/api/storageservices/create-service-sas#revocation-of-a-sas
• https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview#types-of-shared-access-signatures
• https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas
• https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview#best-practices-for-using-sas

Paulus

This answer is definitely the best as it is the only one that gives a mechanism for immediately revoking a Shared Access Signature that is NOT based upon a policy. I have tried refreshing the primary account key and can testify that a shared access signature on a blob container was immediately revoked. Note that in Storage Explorer when generating a SAS for a container, you cannot choose which account key to sign it with, so I guess it's always the primary. – Orgeat

"... only five SAPs can be attached to a storage account". Actually, it is "only five SAPs can be attached to a blob container". Link – Korwun

@liki thanks for catching that mistake ... fixed it. – Paulus

Answer 3

You can't revoke a shared access signature unless it is based on a stored access policy. See https://learn.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy#modifying-or-revoking-a-stored-access-policy for more information:

To revoke a stored access policy, you can either delete it, or rename it by changing the signed identifier. Changing the signed identifier breaks the associations between any existing signatures and the stored access policy. Deleting or renaming the stored access policy immediately effects all of the shared access signatures associated with it.

Slant

Can you please provide simple code for removing Stored Acess Policy or changing Signed Identifier – Tendinous

Why should Azure even allow creating a SAS key without a Storage access policy then? Ability to revoke access is a basic requirement for any authentication system. – Cassiterite

Is there a way to do that nowadays? I generate SAS tokens programmatically that expire in 1 hour but sometimes I want to revoke it earlier than that time if the operations associated to it are completed. – Loram

From my understanding, SAS tokens is a string containing encrypted information about what it is allowed to access. This allows the developer to generate an infinite amount of SAS tokens without overhead, but with the downside that they can not really be revoked. – Hattiehatton

According to the docs, revoking an ad-hoc SAS, ie not based on a stored access policy, can only be done by regenerating the account keys. – Exultant

Answer 4

Came across this topic too. As per highlighted by @IlyaBerdichevsky on the top, Best practice is to use a SAS derived from a Stored Access Policy.

TLDR;

Watch this youtube tutorial

---

(Step by step) How to create a SAS Derived from Store Access Policy?

First, setup Stored Access Policy

1. Go to your Azure Storage Resource
2. Click on containers (left panel under Data Storage), choose your container (because different container may setup different policy).
3. Click on Access Policy (left panel under Settings)
4. Click on Add policy
5. Here you may specify the desired policy you want (Sample in screenshot)
6. Click on OK
7. Tap on Save button on top (it reflects quickly actually, although it claimed to take about 30 seconds)

Second, generate SAS based on the SAP (Stored Access Policy) created

1. Back to Azure Storage Resource
2. Click on Storage Explorer (preview)
3. In my case I'm using Blob container, so I'll expand my blob container and click on the container I want. You shall see your file inside the container, once you've selected.
4. Right click on the file, click on Get Shared Access Signature.
5. Select the policy you have just created under the dropdown.
6. Tap on create
7. DONE! You've gotten your token now :)

How to revoke/extend the SAS token created for client?

1. Back to the policy you have setup
2. Update the expiry time
3. Save
4. TAAA-DAHH! Same link with the SAS token should expired/work now.

Pittsburgh

Answer 5

I had the same problem and this is how I solved it:

The communication between the redacted service and Azure Blob Storage is done through the SDK v8.0.

Laevorotation

So your revocation is reliant on the client sending a DELETE? Seems problematic when you have any kind of uncooperative/broken client. – Grind

@Grind please note the client was signed in as an admin in this case. Of course, you can do it entirely on the server as well. – Laevorotation

If the upload is done directly from the client to Azure Blob Storage (which is kind of the whole point of SAS), then I assume the server doesn't see the 201 from Blob Storage. Would you just wait for another POST /storage/blob/token to revoke, then, or perhaps use something like a Blob Storage trigger to delete the policy? – Grind

I would suggest to use something like the trigger you proposed. For me, that sounds like a correct implementation. Assumptions: limited to 5 policies (is this still the limit?), trigger is available. – Laevorotation