Azure Shared Access Signature creation

Question

I am generating a shared access signature(SAS) for one of the blob containers which is v 2 using the Azure portal. I am trying to upload a file from frontend for which SAS is required. The problem is SAS is expiring every day. Is there a way to update the SAS automatically using the code or is there a way to do the authentication using Azure AD. So Basically I have a front end where user logs in using Azure AD, now i want to utilize his session to allow him to upload to Azure storage. As he is already authorized, i feel there should be a way to generate SAS on the fly for his session.

You can simply create a Shared Access Signature that does not expire in a day. You just have to select a proper expiry date. — Gaurav Mantri
No it won't. What I was trying to say is that when you are creating a SAS, you create one that expires in say 30 days (and not one day). — Gaurav Mantri
So Basically i have a front end where user logs in using Azure AD, now i want to utilize his session to allow him to upload to Azure storage. As he is already authorized, i feel there should be a way to generate SAS on the fly for his session.@GauravMantri — Hari om Mishra
Please refrain from asking questions in comments. Instead, please edit your question and include all the details there. — Gaurav Mantri

rickvdbosch rickvdbosch · Accepted Answer · 2019-06-17T10:20:56

Shared access signatures are useful for providing limited permissions to your storage account to clients that should not have the account key.

If you are the one writing data to the storage account, do so server side. If you do that, you can validate the user is logged in. If that's the case, allow your backend to write in the storage account using one of the access keys (or better yet, a managed identity.

Of course, you could have your front-end request a SAS token from the back-end, for instance from an API. This could simply be implemented, for instance using an Azure Function. And the SAS token could use near-term expiration times. In the end, you're still opening up parts of the storage account to anyone who can access the frontend.

With near-term expiration, even if a SAS is compromised, it's valid only for a short time. This practice is especially important if you cannot reference a stored access policy. Near-term expiration times also limit the amount of data that can be written to a blob by limiting the time available to upload to it

Source: Using shared access signatures (SAS)

Taken from that same article:

The following code example creates an account SAS that is valid for the Blob and File services, and gives the client permissions read, write, and list permissions to access service-level APIs. The account SAS restricts the protocol to HTTPS, so the request must be made with HTTPS.

static string GetAccountSASToken()
{
    // To create the account SAS, you need to use your shared key credentials. Modify for your account.
    const string ConnectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
    CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);

    // Create a new access policy for the account.
    SharedAccessAccountPolicy policy = new SharedAccessAccountPolicy()
        {
            Permissions = SharedAccessAccountPermissions.Read | SharedAccessAccountPermissions.Write | SharedAccessAccountPermissions.List,
            Services = SharedAccessAccountServices.Blob | SharedAccessAccountServices.File,
            ResourceTypes = SharedAccessAccountResourceTypes.Service,
            SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24),
            Protocols = SharedAccessProtocol.HttpsOnly
        };

    // Return the SAS token.
    return storageAccount.GetSharedAccessSignature(policy);
}

Azure Shared Access Signature creation

1 Answers