Better Understanding of Purpose of Signed Identifiers in Blob Storage (Azure)

0
votes

I am trying to get an understanding of the purpose of signed identifiers when using Shared Access Signatures with Blob storage in Azure. I know that signed identifiers are basically applied at container level and are a named. Furthermore, I know that they provide any Shared Access Policies to be valid for longer than an hour (as opposed to when not specifying a signed identifier). I guess my question is couldn't you just apply a shared access signature at the container level with appropriate permissions and expiry time? Thanks to all that reply.

Okay, I think I get now. So best way to interpret SI's are that they are another level of abstraction for access control at the container level. Furthermore, they allow you to specify how long policies can be applied before they are revoked. In both explicit and SI declaration, revocation is pretty much the expiry time.

So my next question is say for instance I have a policy that has been compromised. How exactly do I immediately revoke or change the policy (being that I've defined this policy in my code; how would I change it without having redeploy code)?

3
azureazure-storage-blobs
I've merged your two accounts together. Please read this Faq entry about cookie-based accounts. Also, StackOverflow isn't a forum; if you have a new question, please ask a new question. If you want to include more information in your question, please edit it. If you want to interact with one of the people who has answered, you can leave them a comment. – user1228

3 Answers

0
votes

The Signed Identifier is how you reference an ACL on a particular Container. These are required for you to create revocable access to your blobs.

If you create an Expiry Time longer than one hour the Blob Service could possibly return a 400 Bad Request Error, or simply ignore the expiry time and set it to 1 hour.

This is done as part of the platform to ensure that your data is secure.

There is more information about the lifetime of a SAS in the MSDN Library

0
votes

The main reason for the signed identifier as opposed to explicitly specifying all parameters has to do with security. If for some reason a SAS was created that had all the parameters specified and had a valid HMAC signature, the blob service would honor it. Imagine there was no limit to expiry time. Now, imagine it leaks. In the normal case, it can only do damage for up to an hour. Rememeber, you have specified all the parameters in it, so you cannot change it. If you could specify an unlimited time, it could not be revoked without actually changing your main storage key (that would invalidate the sig and break all existing SAS). The SI gives you one more layer of abstraction to prevent having to roll storage keys.

The signed identifier (or policy as I like to call them) is the way to extend past an hour and still be able to a.) immediately revoke if necessary or b.) immediately change. With the SI, you can change the permissions, you can delete it, you can change the expiry, all of which give you greater control over the life and access of your existing SAS (the ones that use SI anyway).

0
votes

Actually I've just answered my own question. I can write code to reference the containers in question and clear out the access policies currently set any container.