what is Shared access Signature - Type of SAS and who control SAS

Shared access signatures (SAS)

  A shared access signature (SAS) provides you with a way to grant limited access to objects in your storage account to other clients, without exposing your account key.

 

  A shared access signature provides delegated access to resources in your storage account.

  With a SAS, you can grant clients access to resources in your storage account, without sharing your account keys.

  This is the key point of using shared access signatures in your applications--a SAS is a secure way to share your storage resources without compromising your account keys.

 

Your storage account key is similar to the root password for your storage account. Always be careful to protect your account key.

Avoid distributing it to other users, hard-coding it, or saving it anywhere in plaintext that is accessible to others. Regenerate your account key using the Azure portal if you believe it may have been compromised

Types of shared access signatures

You can create two types of shared access signatures:

Service SAS.

The service SAS delegates access to a resource in just one of the storage services: the Blob, Queue, Table, or File service.

See Constructing a Service SAS and Service SAS Examples for in-depth information about constructing the service SAS token.

Account SAS.

The account SAS delegates access to resources in one or more of the storage services.

All of the operations available via a service SAS are also available via an account SAS.

Additionally, with the account SAS, you can delegate access to operations that apply to a given service, such as Get/Set Service Properties and Get Service Stats.

 You can also delegate access to read, write, and delete operations on blob containers, tables, queues, and file shares that are not permitted with a service SAS.

 See Constructing an Account SAS for in-depth information about constructing the account SAS token.

Service SAS URI example

Here is an example of a service SAS URI that provides read and write permissions to a blob. The table breaks down each part of the URI to understand how it contributes to the SAS:

https://myaccount.blob.core.windows.net/sascontainer/sasblob.txt?sv=2015-04-05&st=2015-04-29T22%3A18%3A26Z&se=2015-04-30T02%3A23%3A26Z&sr=b&sp=rw&sip=168.1.5.60-168.1.5.70&spr=https&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

Name	SAS portion	Description
Blob URI	https://myaccount.blob.core.windows.net/sascontainer/sasblob.txt	The address of the blob. Note that using HTTPS is highly recommended.
Storage services version	sv=2015-04-05	For storage services version 2012-02-12 and later, this parameter indicates the version to use.
Start time	st=2015-04-29T22%3A18%3A26Z	Specified in UTC time. If you want the SAS to be valid immediately, omit the start time.
Expiry time	se=2015-04-30T02%3A23%3A26Z	Specified in UTC time.
Resource	sr=b	The resource is a blob.
Permissions	sp=rw	The permissions granted by the SAS include Read (r) and Write (w).
IP range	sip=168.1.5.60-168.1.5.70	The range of IP addresses from which a request will be accepted.
Protocol	spr=https	Only requests using HTTPS are permitted.
Signature	sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D	Used to authorize access to the blob. The signature is an HMAC computed over a string-to-sign and key using the SHA256 algorithm, and then encoded using Base64 encoding.

Account SAS URI example

Here is an example of an account SAS that uses the same common parameters on the token. Since these parameters are described above, they are not described here. Only the parameters that are specific to account SAS are described in the table below.

https://myaccount.blob.core.windows.net/?restype=service&comp=properties&sv=2015-04-05&ss=bf&srt=s&st=2015-04-29T22%3A18%3A26Z&se=2015-04-30T02%3A23%3A26Z&sr=b&sp=rw&sip=168.1.5.60-168.1.5.70&spr=https&sig=F%6GRVAZ5Cdj2Pw4tgU7IlSTkWgn7bUkkAg8P6HESXwmf%4B

ame	SAS portion	Description
Resource URI	https://myaccount.blob.core.windows.net/?restype=service&comp=properties	The Blob service endpoint, with parameters for getting service properties (when called with GET) or setting service properties (when called with SET).
Services	ss=bf	The SAS applies to the Blob and File services
Resource types	srt=s	The SAS applies to service-level operations.
Permissions	sp=rw	The permissions grant access to read and write operations.

Controlling a SAS with a stored access policy

A shared access signature can take one of two forms:

·         Ad hoc SAS: When you create an ad hoc SAS, the start time, expiry time, and permissions for the SAS are all specified in the SAS URI (or implied, in the case where start time is omitted). This type of SAS can be created as an account SAS or a service SAS.

·         SAS with stored access policy: A stored access policy is defined on a resource container--a blob container, table, queue, or file share--and can be used to manage constraints for one or more shared access signatures. When you associate a SAS with a stored access policy, the SAS inherits the constraints--the start time, expiry time, and permissions--defined for the stored access policy.

Note

Currently, an account SAS must be an ad hoc SAS. Stored access policies are not yet supported for account SAS.

The difference between the two forms is important for one key scenario: revocation. Because a SAS URI is a URL, anyone that obtains the SAS can use it, regardless of who originally created it. If a SAS is published publicly, it can be used by anyone in the world. A SAS grants access to resources to anyone possessing it until one of four things happens:

1.    The expiry time specified on the SAS is reached.

2.    The expiry time specified on the stored access policy referenced by the SAS is reached (if a stored access policy is referenced, and if it specifies an expiry time). This can occur either because the interval elapses, or because you've modified the stored access policy with an expiry time in the past, which is one way to revoke the SAS.

3.    The stored access policy referenced by the SAS is deleted, which is another way to revoke the SAS. Note that if you recreate the stored access policy with exactly the same name, all existing SAS tokens will again be valid according to the permissions associated with that stored access policy (assuming that the expiry time on the SAS has not passed). If you are intending to revoke the SAS, be sure to use a different name if you recreate the access policy with an expiry time in the future.

4.    The account key that was used to create the SAS is regenerated. 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.