Shared Access Signature is a delegated access mechanism available for Azure resources and account. Based on the documentation here – https://azure.microsoft.com/en-in/documentation/articles/storage-dotnet-shared-access-signature-part-1/, it is clear SAS is never linked to a user principal. Thus making it vulnerable to repudiation and defeating the very meaning of access.
Please help me in understanding the rationale of using SAS the way it is implemented Azure.
I don’t agree with your characterization of vulnerable to repudiation
A repudiation attack happens when an application or system does not
adopt controls to properly track and log users’ actions, thus
permitting malicious manipulation or forging the identification of new
actions. This attack can be used to change the authoring information
of actions executed by a malicious user in order to log wrong data to
log files. Its usage can be extended to general data manipulation in
the name of others, in a similar manner as spoofing mail messages. If
this attack takes place, the data stored on log files can be
considered invalid or misleading.
You don’t want to give the user your Azure access key.
You have the option of providing a SAS with a life time. If set up properly the SAS can be disabled. Yes the user could share the SAS with someone else but they could also just download the blob and share it to someone else.
If you don’t like that level of access control the don’t use it. Only serve up files from the server side application (e.g. web site or web service).
I makes for fast scalable applications. If you are serving up some large BLOBs then you just send a SAS and the file is downloaded directly from BLOB strorage. That traffic does not hit the web server.
2